Application security programs vary from company to company. The ineffective programs have many of the same characteristics.
#1 Failure to Involve AppSec
Where appsec involvement is limited or too late in the SSDLC can result in expensive fixes and breaches later. Some programs significantly limit the scope of their application security group to just a few responsibilities. As long as the entire SSDLC has coverage by a group, that is acceptable.
See more about a robust SSDLC here: Application Security
#2 Lack of Security Requirements
Lack of requirements either non-functional or project specific can result in misconfigurations and vulnerabilities. Requirements need to be in a ‘shall’ format and not leave any wiggle room for people to misinterpret or go around the defined requirements.
There should be high level requirements that are common among all applications. It may be helpful to have a set of requirements that are prewritten before design/development begins. some examples are below:
- The application shall use HTTPS
- The Open Source components shall be the latest stable version.
- The principal of least privilege shall be in accordance with X, Y Z…
#3 Unclear Processes
It’s one thing to write a robust procedure, its another thing to make sure that they are communicated and followed. Additionally, there should be security “gates” that ensure the processes are followed. For example, if you write a set of processes, are you sure that employees are following them? Someone (a person or a group) should review the application against the applicable set of processes.
#4 Lack of Metrics/Reporting/Transparency
Metrics are a valuable tool that show areas that need improvement or show program status. There will always be a need to improve the program and at times, metrics may make your job stressful. Showcasing where the program needs improvement may put you in an uncomfortable position when presenting to upper level management; Do not be intimidated! The metrics should be an honest representation of the program. As long as you are making improvements and showing that over time, you will be more respected for the honesty than using “fluff” or “feel good metrics.” “Fluff” or “feel good metrics” are metrics that are either are not a true representation of the program or useless metrics that look good to executive staff. People will eventually see through the “feel good” metrics.
#5 Need for Security Awareness Training
Security awareness training is simply training your developers and team on what the latest best practices are for design and development. A yearly training or new employee training proves to be effective. Developers may not always be security conscious. It’s your job to ensure that security best practices and requirements are being communicated to the team. If there is a developer who loves to incorporate security, consider that person an ally to the group and highlight that person. Its likely that they will help convey those practices to the rest of the team – we can’t do it all! We need to empower the developers and project team to do well.
#6 Application Inventories are lacking or don’t exist
An application inventory is a database that has a list of all of your applications. If this does not exist, or is not frequently reviewed and updated – it is highly likely that you will miss something. Also, the need for this database and accuracy significant goes up with the size of the company.
#7 Too much or not enough automation?
Relying 100% on automation or having 0% will affect your organization. It may seem like 100% automation is the way to go but the reality is that human review, especially during the design phase is critical. The right balance varies per company but it is common for the CI/CD pipeline to have unreviewed releases that actually have vulnerabilities that would have been caught if a human had reviewed the release. Alternatively, 0% automation will result in an extremely slow release process that could also introduce vulnerabilities because a human did not thoroughly review a portion of the SSDLC where a tool or script would have caught easily.
If you are starting with 0-10% automation, work your way up slowly. The team should understand the process well and be able to do the tasks without a tool before one is added in. For example, if you are incorporating a SAST tool into the CI/CD pipeline, one should be comfortable with reviewing code and following the code review process. This will ensure that the company chooses right tool and that it will be implemented properly.
#8 Poorly tracked Bugs/Vulnerabilities/Risks
Tracking vulnerabilities/Vulnerabilities/Risks using an effective tool is imperative. Its one thing to record them but entirely another to follow up and ensure they get remediated. An important metric that can be generated from this is ‘Mean time to remediation,’ or the typical amount of time that it takes to remediate a vulnerability, bug or risk.
Other Resources
Sample Pentest Rules of Engagement