The CISO’s Guide to Application Security Innovation
Table of Contents
Threat actors operate by an ironclad rule: If it’s important to businesses, it’s important to them. And they certainly understand the crucial business role of applications. Applications are now the number one attack vector, while software supply chain attacks increased 650 percent in a year.
Clearly, if you don’t already have a modern application security program, you need to build one. But how do you make sure that your program will be effective? Let’s start with the following tips.
1. Find out what you don’t know
It may sound obvious, but you need to identify what you don’t know to find crucial knowledge gaps and identify issues. This means asking a lot of questions, starting with the following:
- Where is your application used?
- What languages does it use?
- How does it communicate?
- Does it communicate externally and/or internally?
- Where are the authentication details stored, a database, an active directory, Okta?
- If they’re in a database, do you store your credentials securely? Are they hashed?
- Do you store credit card information and if so, all or some of each card’s details? Could this information be critical in the event of a breach?
2. Educate from the top down
To successfully integrate application security across the entirety of a development program. everyone plays a role, from the C-suite all the way down to the developers. Here are some ideas to get everybody on board:
- Communicate with the C-suite. Make sure that the CEO, and CIO, all the way from the top down, understand what you’re doing and the tools that you’re using. If there are any gaps, ensure they know, because it’s crucial that they buy into the need for modern security in today’s environment.
- Hold an annual company-wide meeting to explain your security program to your developer community. Sharing this information company-wide helps to build a relationship with developers. The last thing you want is a situation where the security team and the development team don’t work together. When that happens, nobody wins.
- Monthly reports to executives. It’s crucial to keep your executives in the loop about where you stand with your security program today, especially if you have teams that are struggling to put resources together to resolve security issues. With up-to-date knowledge, executives are better placed to make judgments, such as reconciling developers’ need to ship product with security’s need to scan and check.
- Monthly newsletters to developers. Publishing regular newsletters to teams of developers gives you an opportunity to highlight news and developments, recent threats and fixes, and current examples of how others have handled them. This is a great way to learn from others how to avoid or overcome the same issues before they impact you.
3. Bake application security into developer onboarding
Start your security training as soon as any new employees arrive. Have a member of the security team spend 45 minutes to an hour talking with everybody about your security program, what tools you’re using, and your approach to security. (At the very least have a recording that you can share.) Then, when your developers start working, they will have the same information and knowledge and you’ll have started them off on the right foot.
Ensure that your developers feel comfortable talking with the security team so that both groups understand the other’s priorities and can work together to overcome any differences. This will encourage developers to make security part of their regular working practices and will hopefully minimize any friction between teams. Also, make sure that your developers understand the tools that you’re using, where they’re scanning, and what the tools are searching for. That’s a process of education and is best performed when working together.
4. Show, don’t tell
Show your teams that they have an issue. It’s more impactful than just telling them, and it gives everyone a stronger sense of urgency to get things fixed. One idea is to create a presentation where you go out and attack your internal software, record your attack so that you can revisit it, and show it. In the process, you start to build a library for yourself.
Another method is to take your build, install it on another machine, and then try to decompile it. This will give you a good sense of how robust your application security really is. You should make sure that you obfuscate your applications so that nobody can decompile it.
5. Attack your software
Similarly, stress test your own software by attacking it. Penetration testing is critical to ensuring secure software. Go into your security tools and take the most critical items that you can find in your reports, like command injections.
You can have a third party check your application with penetration testing. But they don’t have access to all the details and the data, so they’re likely to come in and blindly start attacking you. If you assign the job to your security team, or if you have a developer that understands what they’re looking at, you can test more precisely with more targeted attacks, so you know where you should try to dig a little bit deeper.
If you’re releasing source code or applications on the web and you’re not taking these little extra measures, hackers will be waiting and looking for code like yours that has vulnerabilities. Be mindful that there are companies out there consistently scanning every single IP address, saving that information, and putting it on a search engine to look at. If you’re not doing anything like this internally, the hackers already have this information, and they’re ahead of you. Again, knowing what you don’t know is important. So don’t limit your penetration testing. Make sure you’re in an environment that is not production. And make sure that the different internal teams know that this is what you’re about to do or what you’re actually doing.
If there are security alerts and monitoring in place, you’re going to trip those. That’s excellent, as you’re getting into the mindset of the attacker so you can learn what to avoid and what needs securing.
6. Build bridges with security champions
Security champions are a great extension of any security program because they can keep their ears to the ground with different teams working on niches within your organization. A security champion on each team has a better understanding of their work and where security issues might arise on specific projects. They can attend the senior tech reviews. They can attend and understand the scrums. They can look at what’s going on, what features are being included, and any problems that are emerging. Security champions can make sure that the security team is coming up with ideas to promote security and ensure that all teams are focused on it. Maybe it’s security awareness month, or weeks when there’s a focus on something specific, like APIs or cross-site script injections. In fact, a good security champion will not only relay important information to the development community, but will also provide feedback to the security exports so that programs, processes, and education efforts can be continuously refined.
This program can work in many different ways. If you’re a smaller company, you might take a champion — a developer — and just make them security only, with a dotted line to the security team, although they’re still in the development arena where they can oversee multiple things. Alternatively, they might split their time 50/50.
Perhaps there’s a large number of developers in your organization and maybe a small cohort of champions. They can share information with groups of developers. Perhaps you’re an international company with people in numerous countries. By appointing security champions, you have people on the ground who understand the local languages and can relay information and educate teams about good practices in a positive way. And from there, you have built the foundations of a robust application security strategy with a framework for continuous improvement that will set you up well to handle the challenge of a fast and constantly evolving application development environment.
Build a proactive AppSec program
About the author
