by Quan Heng Lim, Cyber-Operations Consultant at Horangi
“The Lean Startup.”
“Fail Fast, Pivot.”
“Agile Methodology.”
The trend today is for teams and projects to be flexible, adaptable, continuously reassessed and developed to ensure that products and/or companies fit market demand.
In the chase to produce the best minimum viable product or to push out the next killer feature, security is often given the backseat. This stems from both market always craving for the new stuff and businesses wanting to be ahead of competitors. What many people have failed to realize, (including myself and some of the teams and projects I have previously worked on) is that in such an environment, taking security into consideration early in the process is even more critical than ever before. Let’s take the typical conditions, looking at cybersecurity both within the product and the environment it is operating in.
Personal experience + some example starts here.
Security is often not given the consideration it should get early in the design or development process and it tends to be costlier to implement later on. Consider this:
- The team comes up with a brilliant idea for a product or to improve a process
- They come up with a fast, efficient plan to implement that idea.
- They pool their resources, gather a team, and roll out their first product.
- People love it, feedback is positive.
- The initial development rush slows.
- Team realizes there are many, many vulnerabilities that were not addressed, some of which require an overhaul of the entire system architecture or methods that are already closed.
I’m pretty sure this sounds familiar to many. So how do we go about solving it, efficiently?
Security, efficiently.
Modern frameworks and languages have many built in features for security, created on the assumption that every developer would take the time to look through the piles of documentation (or lack thereof). Combine this with the fact that third-party code or library integration is almost unavoidable these days. It is important from the onset to set simple rules to help ensure coding best practices are followed while dealing with the sheer number of technologies and languages that can be involved in a single project.
This might seem like it diverges from security, but factors such as maintainability, DRY (don’t repeat yourself), KISS (keep it simple stupid), the UNIX principle and clarity of code helps with security reviews and code revisions while assisting in avoiding logic errors and other issues. Hardcoding of credentials and other sensitive data prevents portability. It should be noted that writing good code is an art unto itself and we will not delving deeply into that for this article.
Best practices include: standardized use of libraries and methods where possible, avoiding using versions containing vulnerable methods, preferring API over system commands when interfacing with underlying system and deciding on proven modules and functions, such as “secure random” instead of “random” methods for a random seed.
Principles such as security of data in transit and at rest and knowledge of the common vulnerabilities in the market today help bring awareness to developers, allowing security to be built into the development process.
Today we will be focusing on this variation of the SDLC:
- Requirements gathering
- Design
- Implementation/Development
- Testing and Verification
- Release and Maintenance
Requirements Gathering
In this phase, we will be gathering requirements for the project ie. the intended outcomes. As part of the SDLC, we should also establish the security requirements and objectives for the application.
Design
In this phase, we will be designing the architecture and depending on the development framework you are using, high level designs of the data models and methods. As part of the SDLC, we should introduce secure design review exercises. A high level security risk analysis and threat modeling should be performed and can include frameworks such as Microsoft’s 1STRIDE. The main purpose of this is to assess risk, determine potential threats, and build mitigation factors or resolve the deficiencies.
Implementation/Development
In this phase, the developers will be getting their hands dirty and coding. Here, we will see the benefits of developer training, development of best practices and standards as suggested earlier. Static code review exercises should be completed with the partial objective being secure code and business logic.
Testing and Verification
In this phase, most development flows will be entering the user acceptance testing. In addition to this, it is a great phase to perform penetration testing and evaluation of security on a stable, release candidate code base.
Depending on the vulnerabilities found and the threat assessed, fixes might need to be pushed out and re-assessed before release.
Release and Maintenance
While most may assume that security takes a back seat on release, this is not true. Especially for newer application releases. The company must also be ready to perform incident response, react to user reports of vulnerabilities, and examine actual exploitation of vulnerabilities.
Depending on the criticality and state of these vulnerabilities, fixes could either be pushed to the next release cycle, require immediate fixes, or best suited with a call to a lawyer.
Is agile & secure development a mismatch?
2At first glance, agile development and security seem to be opposed to each other, with agile being focused on functionality driven, speed and flexibility in short cycles with limited documentation. Security on the other hand, concerns itself with stable code, and extensive analysis with non-functional objectives. This gap can be reconciled by dividing the tasks into three lists:
- One time tasks, such as high level risk assessments, baseline threat models and a response plan.
- Unavoidable checks done every sprint, such as input validation, output encoding, secure response headers, HTTPS settings, updating threat models, and hardcoded keys. Note that some of these tasks can be done cumulatively, depending on sprint length and changes made in that sprint.
- Bucket requirements containing security verification tests, design review and planning updates (response plans, threat models etc.)
As with the development cycle, ensure that there are security-savvy people providing some overwatch in the development process, managing the design, follow-up on issues and monitoring the risks.
Last words.
Implementing security early makes it easier to do in the long run, and I hope the above article has given you some insight on where to start.
- The STRIDE Threat Model. (n.d.). Retrieved May 03, 2017, from https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
- Win, B. (n.d.). Secure Development LifeCycles (SDLC) (Tech. No. SecAppDev 2014).
Quan Heng Lim is a Cyber Operations Consultant for Horangi. He was the founder of 2 technology based startups before throwing himself into cybersecurity and penetration testing. These days he enjoys breaking stuff as much as making them, helping other companies discover security vulnerabilities and providing general technology consulting advice.
