Best Practices For Secure Application Development

Information security and cyber security can sometimes appear to be shrouded in a culture of fear and paranoia. Whilst this can be a powerful motivating force, boards, CEOs, and security advisors must take care to ensure these emotions do not result in fatigue, avoidance or complacency with employees.

Companies that develop software or applications face additional challenges and need to pay particular attention to how they incorporate the use of tools into their DevOps practices and processes. Here are five key actions that I have seen from interactions with our customers and developments in the field which can help to improve security posture: creating an internal awareness; “shifting left” during the development process; relying on trusted advisors; penetration testing applications; and monitoring use of third-party libraries.

Create internal awareness

Good application security starts before any software is developed. Creating an awareness across your entire business is important as any weak links are exploitable.Consider the following:

Staff onboarding – this process should incorporate security training and awareness modules presenting hypothetical security problems and approaches to help mitigate or prevent a breach. Electronic training modules should incorporate an assessment and need to be part of learning and development, regularly revised and re-assessed.
Reminders – use small, subtle reminders of good security practices in the form of screensavers or posters in prominent locations. For example, “CTRL-ALT-DELETE when you leave your seat.”
Phishing tests – these tests should be designed to reward positive outcomes rather than punish negative results. Run these regularly enough to confirm strong awareness in your business but do not over-test as this can create apathy.

Shift-left DURING THE DEVELOPMENT PROCESS

When we talk about shifting left on security, we are placing an emphasis on discovering and detecting problems early in the design phase for a project. Application and infrastructure architecture must focus on threat modelling and adherence to secure design patterns. Cloud platforms such as AWS, Azure and Google all provide whitepapers on how to architect for security; drawing on observations gained from real-world security breaches and lessons learned as part of remediation.

Security analysis tools should be used in your development tools, workflows, and DevOps pipelines to detect vulnerabilities. Development methodologies should incorporate security checks, for example, including them as part of validating against the “Definition of Done”.

Technical leadership also needs to promote a culture where team members close to the code are encouraged to raise security concerns. Ensure that teams move quickly to prioritise investigation of issues and never punish anyone who raises what they think is potentially a trivial security issue.

rely on trusted security advisors

If your business isn’t large enough to have a CISO or dedicated security team who can endorse your position you may benefit from an independent review of your application landscape and security processes.

Trusted security advisors who can perform independent reviews should provide you with unbiased, prompt advice. Your advisors should be able to provide board-level consulting services and help you build a security capability internally if this is your intended direction. Proper long-term strategy will require allocating a sufficient annual budget for periodic infrastructure and application penetration tests and staff security training.

Talk to at least three different potential security advisors and research their key staff to get a sense of fit and credibility. Ask for references that include how active they are in the security community, how technically proficient they are, and how capable they are in governance.

Penetration test your applications

Application penetration testing can be either black-box which assumes no knowledge of the inner workings of the application or white-box where details about data, APIs and interfaces are known. Your system under test should use configuration and a deployment topology which is as close as possible to your production environment and it should only be provisioned for the duration of testing or re-testing.

When preparing for a penetration test, obtain a list of the OWASP (Open Web Application Security Project) test cases that your application will be validated against and create stories in the product backlog to ensure your application defends against each test case. If you are unable to mitigate against each threat prior to testing, at least focus on the OWASP “top ten” threats which evolve each year.

It is important that the entire team developing your application is involved in preparation work and that you create test user accounts administrative and non-administrative privileges. Load test data into the system which allows for destructive end-to-end workflow testing.

When penetration testing on AWS or Azure cloud platforms, you generally don’t need prior approval however pay attention to requirements and restrictions to ensure that you do not perform any actions that breach cloud platform terms and conditions.

You should have a primary and a secondary contact person for co-ordinating responses or managing the system under test. This person should have the ability to lock or unlock accounts, change passwords, load test data, and restart the system. They will also be the first point of contact with the security team.

Vulnerabilities found during testing which have critical or high CVSS scores should be rapidly triaged and prioritised for resolution if necessary.

Once testing has finished, review vulnerabilities in the test report as a team and make an informed decision whether to resolve issues based on their CVSS score and your company risk profile. Do not deploy any software that contains critical or high severity issues and consider remediating medium severity issues before deploying to production.

Monitor use of third-party libraries

The recent zero-day Log4Shell vulnerability highlighted the challenges associated with depending on third-party libraries. Your DevOps toolset must provide the ability to perform static code analysis to find potentially vulnerable libraries. When found, teams should prioritise remediation, patching and deployment of critical fixes above anything else.

Use build tools to produce a “software bill of materials” (SBOM) which is a key building block for transparency and software supply chain risk management. An SBOM can be used to reduce security risks, licensing risk, and compliance risk and it should be readily accessible for authorised users or stakeholders.

Summary

It is no longer acceptable for organisations to drift towards a better cybersecurity posture*. What it takes, is a concerted effort with board level support and proper funding to embed a security-first mindset in all employees. After all, it is people - the human firewall - who are the first line of defence in building a good security posture.

Having focused on raising awareness with employees, you also need to leverage security tools and software that can be embedded in your application infrastructure. Companies that develop software should use static analysis tools and embed these using DevOps practices to continuously find and fix security vulnerabilities. Validate your thinking and activities using guidance from trusted security advisors.

Whilst this can sound overwhelming, it starts with small steps which when combined, contribute to providing your organisation with an improved security posture.

*https://csrc.nist.gov/glossary/term/security_posture

Greg Smith is the Head of Engineering at Jade. Greg has more than twenty years of experience architecting and implementing systems and products at scale in healthcare and finance. He is a firm believer in pragmatism and balancing the needs of business and technology teams.