Getting security into the software development life cycle (SDLC) seems easy. Just write good code and wallah security is in an application. That would be nice, but unfortunately, it doesn’t work like that.
The very first step to implementing security in the SDLC is to have support from leadership. I was lucky enough to have that when I was tasked with this responsibility. Before a new application went live, management asked if security had reviewed the application. Simple. Sweet. It made my job a lot easier. I didn’t have to constantly track down applications or bang the developers over the head. They were coming to me. Which was important in improving the process as the security assessment program matured.
The next step is to get familiar with the tools. OWASP ZAP and Burp Suite are two low-cost tools that can help with performing a security assessment. ZAP is free and Burp Suite costs $350 for the professional version. I’ve covered ZAP in a previous post. Both tools have plenty of resources available to start diving into.
I highly recommend training. I took SANS 542 and it helped tremendously. I learned a lot about the methodology and vulnerabilities associated with application security. If you happen to be in the southeast you may be able to catch a Tim Tomes training course. Troy Hunt’s stuff on Pluralsight is also a really good resource.
Security should be implemented at all stages of the SDLC. Which means a security person should be involved in the early stages, as well as the late stages. The should be at planning meetings making recommendations. They should also be tracking and checking in on progress. Towards the end is where the actual security assessment occurs using tools like ZAP or Burp, but the work doesn’t end there. Confirming findings and generating a report starts the next phase. Finally, Remediation is an important step and requires working closely with the development team.
Working with developers and system administrators
Working with other departments is vital in implementing strong security. For simplicity sake I’m going only going to mention developers. However, don't forget the system administrators. Developers build the applications and the sysadmins are the ones that maintain it. Some findings will require the help of sysadmins configuring the servers that run these applications. Do not overlook them.
There are two big no-nos in working with other departments. Not confirming findings and not providing guidance on findings that need to be resolved.
Confirming findings is very important. Each false positive that a developer finds is credibility the security team loses. Developers have enough on their plate, with applications to build and ambitious deadlines to meet. They don’t need to spends hours on a problem only to find out that the security team made a mistake. Scanners do make mistakes. Make sure each findings are confirmed and can be explained. This goes along with the second part.
Work with the developers to resolve the findings. Vulnerabilities in code will need the security team's help in remediation. Developers are really smart. In my situation, a lot of the time, the developers knew how to fix the issue. But other times, I had to help them research a solution. New vulnerabilities are being discovered daily and it's the security team's responsibility to be on top of them.
One of the benefits of helping developers resolve issues is that it gives us an opportunity to build a better relationship with them.
Building a relationship allows for an easier transition to security. As I mentioned earlier, developers are under a lot of pressure to get things up and out. Security can come in and add more pressure or it can allow them to make better applications. Enabling them to do their best is our goal. A relationship with the developers will make that transition much smoother.
How to build a better relationship
Ask the questions. People love talking about what they do, especially, if they’re passionate about it. Ask questions and show an interest in their work. Coming from a non-development background meant I had a lot to learn. Which gave me plenty of opportunities to ask questions. By making an effort to understand their work, I gained credibility as a problem solver. I showed that I wanted to understand their work.
Help solve the problems. ZAP reports have a reference and solutions section. Go through those. Get on Google. Review YouTube videos. Read blog posts. Do whatever is needed to understand the fixes for code. Then dive into the code with the developers to understand the fix. Provide the developers with as many resources as possible to get the job done and then learn from them.
Teach them the tools. This goes back to implementing security at all stages of the SDLC. The earlier issues are caught, the less it will cost to resolve. This is where leadership support comes into play. With leadership ensuring that the SDLC ran through the security team it helped create the story below.
Storytime
After running several security assessments for new applications, the developers wanted to know more about the tool I was using. If they’re going to have to run an application by me, they want to understand the tool I'm using. Each time I found something meant time we had to go back and remediate and then re-scan. So, I started showing them how to run ZAP. I did one-on-ones with developers and held training sessions on the use of the tool. Something amazing happened as a result of that.
One day, we started receiving reports that a scam email was being sent to customers via our service. The thought was that as people signed up for a new account, they would receive a scam email. Not something we wanted to take lightly. While I investigated the message of the scam, I asked one of the developers to go create an account. The idea was to see if the scam email did in fact come after account creation. So he did.
He returned to me and told me that there was no scam email after account creation. He then handed me the ZAP report. Wait. A ZAP report? Mind blown. I hadn’t even asked him to use ZAP while checking for the scam email. I had intended to do that myself, but he went ahead and did it.
That likely doesn't happen if leadership isn't committed to security.
*By the way, ZAP wasn’t built by someone in security. It was built by Simon Bennetts, a developer. This tool was built by a developer, for developers. Security people just thought it was a neat tool.
Conclusion
Leadership support is important to the successful implementation of security into the SDLC. Tools are a wonderful way to get started with finding vulnerabilities. They are by no means perfect. As the program matures more manual and in-depth testing is needed. Training can help with that. Also, stay on top of the latest application security news. There's something new every day.
Security needs to be implemented at all stages. Which means attending developer planning meetings. Tracking project status. More importantly, understanding the business needs in application development. Interviewing and meeting with project managers and developers individually.
Finally, work with the developers and sysadmins to resolve issues. Be there as a resource and a student to their craft. Ask questions. Solve problems. Teach them the tools. It will go a long way in enabling them to be better.
This post first appeared on Exploring Information Security.