Built-In, Not Bolted-On—What It Takes To Build-In Info Security


Application security is more critical now than ever before.  Given the increasing trend of remote access to applications and online transactions by end-users the attack vector is growing larger.  And with undetected vulnerabilities, the applications face the potential risk of security attacks some of which could even bring down the business.  Therefore protecting an application is as critical as designing it with user-friendly features and making it available.

With a continuous focus on security, the National Institute of Standards and Technology (NIST) keeps updating its controls and guidelines – NIST SP 800 – using cyber threat data across the globe.  NIST has released its next version (Version 5) of SP 800-53 as recent as Sep 2020.  This clearly shows that security is not a one-time step but a continuous process of review and improvement.  

When it comes to security the best approach is to build security into the application as it is designed and developed.  It has been proven that security bolted on after the application is built has not been effective and has rendered itself weak leading to compromise or breach. 

This article highlights the different aspects that help an organization build in security right from the early stages of application design and development.  It provides a holistic approach to build in security considering that security is not the sole responsibility of the development team alone.

1. Leadership Commitment and Visible Support

Security takes a back seat unless it is supported by the leadership.  The leadership should understand why security is important and enable the development of policies and standards for application security.  They should include security along with the business priorities and visibly demonstrate their commitment through investment, communication, and governance. They should play an active role in determining the security appetite of the organization.  They should encourage the usage of modern tools and techniques to build and verify security controls.

2. Investment

IT security comes with its cost.  The leadership should be willing to provide an adequate budget for security to be included in the application design and development cost.  The C-level executives should buy in the necessity and significance of building in security in applications and the risk of not protecting them. The cost of building in security could include a range of items from tools and infrastructure to training. It is the responsibility of the security officers or expert consultants to provide a picture to the leadership showing the security threats and the financial and non-financial implications if an application is compromised.  

In addition to the cost of building in security, the investment budget should also include the cost of recovering the applications in the event of a security breach,   For each application, the security experts should perform a risk analysis and define the security controls required to address these risks.  They should determine the Maximum Tolerable Downtime (MTD) for these applications and compute the cost to recover them within the MTD.  

Further, the budget should also include the cost of continuous validation and improvement including periodic audits and assessments. security tools upgrade and other such elements.

3. Roles and Responsibilities 

With the increasing recognition of IT security as a business priority, the role of Chief Security Officer (CSO) has become critical not only in large corporates but also in medium-sized companies.  In many organizations, the CSO is at the same level as the Chief Information Officer (CIO) and reports directly to the CEO. While the leadership sets the direction for the security program of the organization they should define the other roles down in the hierarchy.  For example, there could be a risk officer, a data protection officer, and other such roles who would focus on different areas of IT security.  They would design and implement security initiatives in their areas.   These officers and their teams should be guided by the organization’s security policies, guidelines, and baselines.   Security implementation will not be effective if it is a part-time responsibility.  Dedicated roles with full time responsibilities will bring the necessary focus and specialization to implement the most appropriate security controls in the enterprise.

4. Governance

The IT security initiative of the organization is well set for success with a clear direction set by the leadership and followed-up through governance.  The officers in charge of implementing application security should keep track of the money spend on the different account heads such as infrastructure, tools and technology, and training.  They should measure the progress against the plan and report to the leadership on key metrics.  

The solution development team on its part should prudently utilize the funds allocated to them to design and implement security controls in the solutions.  They should report back to the CSO on the technical accomplishments in terms of security controls to provide confidence to the leadership.   They could conduct periodic vulnerability assessments and penetration tests to make sure that they are identifying and addressing security vulnerabilities.

5. Hacker’s Mindset 

This is one of the key enablers to build-in security in the applications.  The development team – architects, designers, developers, and testers – along with the ops team should think like hackers.  They should study the existing defenses and understand how they are built.  They should think about how attackers could bypass control.  They should constantly look for ways to break their own defenses in order to improve and make them stronger.   They should conduct threat modeling at the beginning of the project and on an ongoing basis to understand new vulnerabilities/threats and make changes to the built-in defense.  They could use a model such as STRIDE®  to implement controls to address Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of privileges.   

6. Infrastructure, Tools, and Training 

The dev and ops team should be equipped with the necessary infrastructure and tools to build in security controls and conduct vulnerability assessments, penetration tests, and threat modeling,  They should have the freedom to set up sandboxes to test their controls.   Occasionally, based on need and with strong security controls and careful monitoring they should be allowed to expose part of their application in the DMZ to check how the application behaves when exposed outside the internal environment.  Care should be taken while placing the application on the DMZ.  The team could perhaps expose the application to the beta users.  

The dev and ops teams should be trained on security models and testing techniques and tools.  They should also be enabled to think like a hacker.  They should be challenged to break the built-in security controls of application prototypes meant for training.  Special training should be provided to the ops team to monitor application usage and identify unusual patterns.  Where IDS/IPS is installed the teams should be trained to understand and interpret the alerts from these systems.

7. Rewards and Recognition

This is an area often overlooked by the leadership.  Teams love tech challenges thrown at them.  The CSO organization should feed the tech teams with challenges and encourage them to take on those.  They could gamify this and conduct events such as hackathon asking teams to break applications and suggests controls to make them stronger.  They should recognize the best ideas and suitably reward them.  The rewards may not be always monetary.  They could be other things such as membership in the ‘hackers guild’ or inclusion in the security advisory panel. Or it could be an opportunity to don the white hat and conduct penetration testing of the next critical application.  Often these are more motivating than the monetary reward.


Application security cannot be taken for granted.  Developers should not make assumptions and they should take due care in their code to release unused memory, conduct input validation, sanitize error messages, and implement many such controls to protect the applications. These should be built-in and not bolted on after the application is fully developed.  The leadership should enable the development team to address security early in the life cycle and build in the necessary controls.  

This UrIoTNews article is syndicated fromDzone