In today's environment, secure development is a must. Secure SDLC practices do exist. However, some are more geared toward a waterfall style development process.
Many companies today are using agile methodologies and require a security process that fits well into their model. Security must be fast and effective while allowing the developers to deliver quickly.
Let's take a look at the processes needed to create a secure SDLC in an agile environment.
The first step in any secure SDLC is training your developers. Developers must be trained on how to write secure code. Developers also need security awareness training to help them be aware of how attackers operate and what they can do to protect their software.
Security training is more than watching a webinar or attending a class once a year. It’s an ongoing task where developers are educated and trained while on the job. When vulnerabilities are discovered in their software, show developers what the vulnerabilities are, how they can be exploited, and how to fix them properly.
Disciplines such as test-driven development have helped encourage the practice of automated testing. Developers create automated tests to test functionality, but security can be tested this way as well. Teach your developers how to write automated security test cases, where applicable, to help build security into the code from the beginning.
When the code is written, regular code reviews help developers to examine the code through new eyes. Taking a little time to show code before it’s completed can help to discover problems that would be much more difficult and expensive to fix in the future. Design in security from the start, and you’ll save much heartache.
Keeping security in the front of their mind will prevent developers from repeating the same mistakes.
Every new environment should start with fully patched servers. Create automated tasks to create servers in a cloud environment like AWS and update them to the latest version.
But that's just the start. An ongoing patch management process is required to make sure your software doesn't become out of date.
Keep up-to-date on security and vendor news to learn when their new patches are available and apply them as quickly as possible. This is especially true of CMS vendors. Subscribe to security advisories for the CMS software you use (here are the links for Drupal and WordPress). When security events occur, patch core files quickly after testing in a secure sandbox.
Automated patch management systems such as Automox, ConnectWise, and ManageEngine can help you to keep up-to-date without slowing you down.
When you have third-party software covered, don’t ignore your own code. Fix bugs found in your code quickly and build continuous integration, delivery, and deployment into your pipeline to make sure patches are delivered to production quickly.
If your systems are on-prem, use firewall best practices to stay on top of your firewall configuration. Create a DMZ. Segment your network to reduce the chances of an attacker finding what he wants.
Protect the most sensitive data with extra measures such as database encryption. Use HTTPS to protect sensitive data in transit.
When in a cloud environment, use the security tools given to you to secure your infrastructure. Use VPC in AWS or Security Center in Azure and monitor your network properly. Misconfigurations in cloud environments can allow attackers to get in and get out undetected.
For example, here are some high-level best practices to secure your AWS environment:
Test-Driven Development (TDD) is a common practice among developers today. The process goes something like this:
It’s also known as “Red-Green-Refactor.” This process ensures that the software works well from the start. When the software is handed off to a tester, they shouldn’t be finding basic bugs. The TDD process weeds them out as you code.
The same can be done for security tests. Granted, not all security scenarios are neatly wrapped up in unit tests. But you can create automated integration tests that work multiple pieces of the software and look for strange behavior.
Think of basic security needs that can be tested easily with automation. For example, if you use security headers (which you should), create an automated test to make sure they’re present in every response from the server. Test your validation rules to prevent unwanted inputs from causing bad behavior.
You can often detect XSS flaws, verbose error messages, and other basic security flaws with automated vulnerability analysis. When a vulnerability is found, find a way to create a test for it so it doesn’t appear again. Tools like OWASP ZAP can be scripted to recreate more complex security issues and run against multiple applications to find vulnerabilities.
Get creative. Find ways to make your devs lives easier by automating as much testing as you can.
Despite your efforts to automate security testing, you’ll eventually need to find more complex vulnerabilities that require human intuition to find. Penetration tests allow humans to poke around in your application to find problems.
Many regulations and standards, such as PCI DSS and HIPAA, require penetration tests to occur on a regular basis. This can be difficult to pull off in an agile or DevOps environment because the focus tends to be delivering and getting feedback as quickly as possible. No one wants to stop and do penetration testing for two weeks.
Penetration testing can be done in an agile environment. Your environments should be created automatically by a build pipeline. Create a new environment in the cloud and deploy your latest production build. Have the penetration testers test in that environment, and report their findings. Then tear down the temporary environment when completed.
The penetration testers won’t interfere with ongoing work and they’ll still get to test an up-to-date version of the application. Their findings can be reviewed and fixed based on severity.
Another option for ongoing security testing is a bug bounty program. Bug bounties pay ethical hackers to constantly search through your applications to find vulnerabilities. Your application will be attacked using real-world attack scenarios and these programs often discover bugs you wouldn’t otherwise find. The testing happens in the background on a continual basis with regular reports coming in.
Your secure SDLC needs a strong vulnerability management process. Finding vulnerabilities doesn’t make your software safer; fixing them does.
Establish vulnerability ratings that make sense for you. It could be a rating from 1-5 or Low, Medium, High, Critical. But use caution when creating your ratings.
Too many rating levels create confusion and slow decision-making. What makes critical worse than high? Is there a practical difference between a 4 or a 5?
A better option is to keep things simple. Andrew Dunbar, VP of Security Engineering at Shopify, mentioned in a recent webinar on application security testing that Shopify has two levels: low and high. High risks are fixed right away. Low risks can be fixed in the next sprint or two.
Once you have a rating system, create SLAs based on those ratings. Hold your developers accountable for fixing vulnerabilities promptly. Security is now an intrinsic part of code quality.
Creating a secure SDLC is a long and winding road. Concentrate on one piece at a time. Refine that piece as much as possible and then move on to the next.
Before long, you’ll have a secure build process you can be proud of. You’ll deliver software quickly, with high quality and security built-in.