Welcome back as we continue our journey to secure applications from their birth to their deployment through Git repos, Docker containers, Kubernetes orchestration, and live in the Google Cloud Platform.
In the previous article, we covered the foundation for security. The business supporting security, and everyone getting trained. Developers created unique accounts and the development environment is in place and ready to go.
In this article, we focus on the programming languages and associated libraries.
What programming languages will they develop with?
Relationship
The most important thing to have in place is a relationship between security and developers. This can be a formally scheduled meeting every quarter. Maybe this is an informal coffee date. Maybe this is an information security manager sitting right next to the manager of the development team. (I like that idea).
A relationship needs to be in place and support continual conversation and agreement. Developers have a hard job. They need to create something out of nothing. They need to take the vision of the company and make it appear. They need to lower company costs and improve client experiences. They need to do it all while worrying about bandwidth, workloads, bottlenecks, read and write times, availability and reports.
Security needs to come alongside them, listen to what they are trying to do and start laying the paver stones so that they have a clear and visibility runway.
Security needs to know what the developer’s objectives and goals are. What their priorities and initiatives are so that we can understand what tools, languages, and resources they need to deliver that solution in a secure manner. We need to get ahead of it and provide the resources, instead of waiting until their done and then telling them they did it wrong and it doesn’t meet our security requirements.
By learning ahead of time what they’re going to develop, we can start the process of providing a secure roadmap. Only when developers do not communicate what they’re working on, and security learns after the fact, do we have some level of right to point out how it was done wrong.
Languages & Libraries
Now that you know what will be developed and what they want to use to create it, you need to decide what your security approach will be approving languages and libraries.
Libraries
For those that don’t know what a code library is I want to explain at a very basic level before moving forward. With development languages like Java, Python, and .NET (among others) you’ll have the core of the development language that comes wrapped in a binary distribution. You install this on your development system or endpoint. This is where the basic coding or programming is done and often referred to as the ‘environment’.
For Java it’s the Java Development Kit (JDK), for Python it’s a combination of a text editor and a runtime environment. And with .NET it is .NET Studio.
Libraries are extensions of the core package and binary that can be imported to increase the capabilities, functionalities, and extend the language. Libraries may include instructions, templates, and pre-written code.
Notice that last part? ‘Pre-written code’. That’s where you’ll need to focus. as the old saying goes.
“A good developer writes code, a great developer steals it.”
So if you allow the use of libraries or pre-written code, you’ll need to create a review and approval process.
I have my personal preference, but I also understand the same process doesn’t work for everyone. Each business is unique.
The two methods are ‘pre-approving’ and ‘post-approving’. Let’s take a look at the advantages and disadvantages of each.
1. Pre-Approving
This approach takes the intake from developers on which languages they want to use and requires security go research that development language and the associated libraries and produce an ‘approved‘ list. This is essentially a formal list of what can be used.
Sometimes this can be very easy. For example, you learn the team wants to develop with Java. You can do some basic research and make a statement like Java 6 is not allowed, but Java 7 is approved. You also have the option of approaching like a policy statement such as,
“Current development code needs to be used. All development must be using current releases, and nothing older than twelve months. If a serious vulnerability or exploit is reported, it must be patched and remediated within thirty days. “
It becomes more difficult when it’s a language like Python, and how and when existing code can be used from their favorite Internet sites.
2. Post-Approving
In this security philosophy, you are giving the developers permission to use whatever they want.
This privilege comes with a price.
A famous quote applicable here, yet used out of context,
“The cost of freedom is always high.”
– JFK
That price is, the developers are ultimately responsible for the security of their own code and applications.
Security will act as the auditor and inspector, but if they are ultimately responsible for the security of it.
The best way to implement this post-approval process is by having a strong relationship with developers, providing them training and resources on security exploits, having strong upper management support and security culture, and lastly having a security ‘ninja’ on the development team.
A security ninja is a security champion. They are a coder with security training. They do the hard application library security lifting, so you don’t have to. They take the security boundaries and authority given to them and they do the best they can with it.
Your role in this philosophy is two-fold:
1. Train – Provide them with all the training on exploits, security, and best coding practices that you can find.
2. Verify – Create a system process and toolset to verify what they are creating is secure. This starts with the highest risk applications and works its way down. For larger organizations, this might be a dynamic code analysis in line during the development process. For smaller companies, this might be a third party code testing tool like Veracode (or similar).
Summary
The criticality of having a strong relationship with the development team cannot be underestimated. Have a process of learning what they are going to be working on, and what tools they will be using.
Develope a security philosophy that will pre-approve language and libraries, or that will support trust and verify methodologies.
Build a relationship with the development team that reduces friction, and can enable them to do deliver great products securely.
If you’ve found a system that works for you, I invite you to share it in the comments section.
Next
In the next article, we will look at application repositories and the importance of storing code in a secure location. For the scope of our project we will examine moving our code into GitHub and what security best practices can be put in place to reduce the risk of secrets being exposed, the secure code being accessed, and the integrity of the application being impacted.
Recent Comments