To get a company ISO certified requires a lot of planning and effort from a variety of parties. ISO 27001 will touch upon hiring policies, safety equipment, physical security and of course operations / application security. My effort, at my job, helped get our company ISO 27001 certified. My effort in a strong SDLC, proper workflow, regularly scheduled security testing, tooling, code analysis, long / application monitoring, and security policies went a long way to get us over the finish line.

SDLC

Having a process for development, through QA, bug finds, bug resolutions, re-testing, merging and deployment will come up in this aspect of certification. How are feature requests or bugs logged? How do developers pull the work, or get it assigned? What is the bug resolution process? Who oversees the merging of code to master? How is the code deployed once it passes quality and security testing? Those questions need to be nailed down with proper documentation and more importantly evidence of implementation.

People may think that ISO certification relates to policy. It does, but it is much more than that. Just having policies may not pass certification. A team needs to show that policies are implemented. Having an internal security and testing wiki, with the OWASP top 10, code analysis methodologies, as well as demonstration of tools all come together to show the SDLC in practice.

An auditor may ask to view the tools used in static code analysis, dynamic code analysis, automated testing, bug reporting, bug validation, and deployment.

As part of my SDLC I also integrate security testing. This was demonstrated to the auditor in terms of manual validation of common (OWASP top 10) vulnerabilities.

Scheduled Penetration Tests

Regularly scheduled penetration tests are extremely useful. Running automated scans, while attempting manual exploitation is a pretty useful approach. Manual work will include corporate OSINT, application security testing, while automated tests may include internal scans of server installed libraries/applications, tools to run common attack vectors on a spidered application, and code analysis.

An auditor will likely request to see evidence of penetration tests (going back several iterations), as well as evidence of automated scans and tools.

Tooling

I create a lot of tools, from web apps that monitor telecom events, to static code analysis. In my case the auditor asked what tools I used for SCA (static code analysis) and I mentioned that I wrote my own. This intrigued the auditor who then asked to see the tool. I was able to showcase the tool and how it works using regex to find owasp top 10 events in code. Demonstrating it working, I also provided the report and went through it with him to show how the results are turned into actionable items.

Monitoring

If you are using a SIEM, IDS, or creating your own through log harvesting, this will help towards certification. An auditor may ask to see the dashboards, the data objects being parsed, as well as the process from which alerts are driven.

Summary

While ISO 27001 certification touches a lot of facets of a corporation, I was able to show high quality in terms of application security, SDLC compliance with security testing baked in, regular security testing (penetration tests), written policies (best practices, security, etc.), as well as monitoring.