Security Think Tank: Effective DevSecOps requires collaboration

Application security

Embedding security throughout the application lifecycle is critical to successfully managing business risks. However, it is important to remember that not all applications need to be “bank vault” secure. 

The first step is to understand the function that the application performs within the business, the data flowing through it, the connections and interfaces established, and the impact should the application no longer be available or reliable.

Ideally, the team assessing the potential solutions in advance of contracts being signed should include security expertise. For applications being developed in-house in an agile way, or undergoing significant upgrades, the assessment should be performed again to understand if the risks have changed.

IT security’s role is then to define appropriate controls to ensure the confidentiality, integrity and availability of the application is maintained. Critically, where possible, these controls should be pragmatic and invisible to users so people are not prevented from doing their job, which results in them being pushed to find ways to bypass them. It is easy for workarounds that circumvent best practice and put applications and systems at risk to creep in. Shadow IT, introduced to increase efficiency, can backfire, jeopardising the security of the organisation.

Applications rarely operate in a silo. Most are connected to other applications, or file servers, via interfaces or connected though business processes, which makes them vulnerable to manipulation or data exfiltration from further up or down the chain. Data from one application might only be considered sensitive when it is combined with data within a second application, resulting in the controls being focused on the latter. However, this leaves the first application open to compromise, which might not be detected and lead to the second (sensitive) application inadvertently being compromised with incorrect data.

Processes to manage the application should also be established. These include how it will be kept up to date, monitoring for new security patches, and integration with any asset management tooling to give full visibility of all the organisation’s applications, along with any changes that take place.

Integration into other existing tools might be required based on risk. For example, critical applications may need to be tied into a security information and event management (SIEM), security operations centre (SOC) or security orchestration, automation and response (SOAR) process to detect any compromise to them. This may not be possible for those hosted by a third party, however, especially if it’s a software as a service (SaaS), so other controls, such as monitoring the Service Organization Control 2 (SOC 2) reports, will need to be performed to ensure they meet any compliance requirements.

Identity and access management

Application security is also dependent on access controls – using technology platforms to design relevant controls to make sure the right people get the right access to the right applications at the right time to perform their job as they need to.   

This is enhanced by identity and access management (IAM) and privileged access management (PAM) tools, which automate processes, thereby reducing the cost and effort of access management, while also making it more effective; a request that might previously have taken weeks can now be undertaken in a matter of days. This is a way to showcase the value that IT brings to the business.

It’s also important as organisations increasingly take a zero-trust stance on security. Access controls can prevent malicious users gaining unauthorised access to systems, create visibility of who has access to what and show how risks around segregation of duty violations are mitigated.

The joiners, movers and leavers (JML) process, integral to business operations but often overlooked, also benefits from access controls. Traditionally requiring heavily manual processing by system administrators and helpdesk personnel, automation frees up resource for more valuable tasks. 

Cyber security

Application security also requires a focus on cyber security. Organisations have a responsibility to monitor for threats that could affect their business operations and ensure that applications and their technology estate are regularly tested and patched for vulnerabilities to prevent hackers entering the system and accessing organisational data.

Automatic updates provide the best defence, while reducing the need for manual software update checks and the subsequent disruption this causes. Updates are applied whenever required, and software applications can be patched as soon as possible to remediate any bugs and fixes. Some care does still need to be taken to ensure critical systems are tested before updates are deployed.

Users accessing applications also have a key part to play – strong passwords, multifactor authentication and password managers all help to secure access to applications. Training on when to use critical access to functionality or data is also required to prevent data breaches or disruption being caused by an individual with good intentions.

Communication

Technology is not the only aspect of application security and DevSecOps – effective upwards communication to senior management also plays a vital role. Technical jargon needs to be avoided, with issues framed from the business perspective.

It’s also important that IT security teams are not perceived as restricting business goals and objectives. Rather than stopping a project because it potentially increases risk to the organisation, involving the teams in question to find ways to mitigate security issues is a more effective approach that meets everyone’s needs. Again, making sure security controls and processes align with the risks faced helps to remove unneeded controls or obstacles that could prevent the business from operating.

When collaborating with projects and change managers, some controls will be non-negotiable from a security perspective. However, to avoid being seen as a “blocker”, security teams need to communicate this in the context of business risk. Compromises can be considered for more minor items, with security teams agreeing to address the issue as part of a wider strategic change, for example, or flag for monitoring throughout the project to see if further action needs to be taken.

Collaboration

DevSecOps requires collaboration between IT security and business functions to provide the business with the vital understanding of its environment from a risk perspective.

Ultimately, application security needs to be incorporated into all aspects of design, to create an understanding of any risks that might apply to the organisation. With this knowledge, the appropriate controls can be established to safeguard the application, its data and – ultimately – the integrity of the enterprise.