Shift Left! Fix earlier! These are the calls that we hear more and more from the industry. And as you evaluate your software development lifecycle (SDLC) and try to determine the earliest, you can perform security testing, you ask how. The traditional method of penetration testing doesn't fit the budget or the schedule of your agile DevOps shop. And your QA and development teams aren't sure how security should be tested.
So how do we do this embedding? At Secure Ideas, we recommend tackling this problem on three fronts:
- Training
- Advisory
- Assistance
Training
The first thing you need to evaluate is how your development teams are being trained. We need to focus on security training without overwhelming the developers. There are two main directions your team can take for this training. (These can work together.) These options are internally maintained and externally maintained.
Internally Maintained
The first option is to provide internally maintained training. This is not as hard as it sounds and has some nice bonuses. The team will need to research options for information. We would recommend OWASP® for information and guidance on topics for training. They have a number of open projects, such as the OWASP® Top 10's and the Security Knowledge Framework. We can work with these types of information to present details to our development teams. One way is to provide quick lunch & learn sessions to better fit their demanding schedules.
Another part of this is to provide information in as many ways as possible. The above-mentioned lunch & learns is one part. You can also provide documentation and policies that focus on security. Teams can also put together a collection of information from the Internet on the intranet for the developers to review when they have a question.
One of the main benefits of internally maintained training is that it can be designed around your organization's goals and concerns. It can also build upon the technology platforms in use by your teams.
Externally Maintained
We also have the option of getting a third-party to provide training to our developers. We here at Secure Ideas are a little biased as we offer options to train your teams. As you work with your training partner, keep in mind the same options as the internally maintained training. The partner should be able to provide options, such as:
- Long-form live training
- Short webinars or lunch & learn sessions
- Recorded training sessions
- Content to share internally
Make sure that your training partner has the option to track compliance with the training since there are many contractual and regulatory requirements around developer training.
Advisory
The second step in building out a developer training program is the advisory function. As mentioned above, this can be performed internally or externally. There are a few things that need to be kept in mind as this program is implemented. Based on our experience helping companies build these programs, we have to think about things such as:
-
Removing barriers to security teams
-
Understanding the development goals and procedures
-
Integrating in the processes
One of the biggest complaints we hear from developers and see when we work with organizations is an us vs. them attitude. Often, advisory efforts are hampered or fail because the advisory is judging you or doesn't understand the concerns. To help with this, the advisors must understand and have experienced development projects. While it may help to use developers, it isn't required as long as the advisor works with an advisor of their own or was a developer. At Secure Ideas, most of our consulting staff have worked as developers or within development projects.
The second item is related to the first. Understanding the timelines, deadlines, and procedures that your security controls must work within is part of being an effective advisor. Too often, we see controls or testing requirements that just don't work within these constraints. Performing a full-blown penetration test within a development sprint is probably going to fail. Adding tools that don't integrate within the tools being used is going to be ignored. And having advice that fails just means the other advice will be ignored. So make sure that your advisory partner and your staff know the platforms and tooling being used and the procedures and processes within your development teams.
Assistance
Finally your program has to include actual assistance. You can't just throw the requirements and training over the wall to development and hope for the best. For Secure Ideas, we have three things we use in the assistance phase. Your organization or training partner should be able to provide these as well.
First, we offer live guidance. Providing a direct communication path during regular development is a great foundation for your assistance. This path has to fit within the normal processes that the developers use. For example we use Slack workspaces but have seen success stories around Microsoft Teams and others.
Second, the assistance has to include things related to testing, including actual testing. Here we use WebScout and Testing Credits, but your organization could build a testing process that does the same thing.
Third, your organization must work with the developers in reviewing reposts and findings. These reports can come from the tooling in place or other testing organizations. We often see problems where the developers don't understand the finding or only address the specific examples shown. The explanation of the entire issue is critical, and this review and assistance help ensure they remediate the issue instead of just bandaging it.
Based on the above, any organization should be able to embed security as early as possible within the SDLC. Let us know if you have any other questions.
