The battle against hackers and threats is an arms race against highly motivated opponents, and with the number of attacks and threats continually growing, it’s impossible to achieve security by simply patching up a broken architecture with single, niche tools.
Originally published in HelpNet Security
The way security groups are typically structured to defend against and respond to threats is similarly flawed. There is an invariable disconnect between where and how security policies are framed, security is enforced, and security is audited. While security officers are responsible for ensuring the integrity of security platforms, they are not the ones charged with developing the security solution to protect them.
They are also not the ones who are able to ensure that the system’s design and development are in complete conformance with the security policy. That is in the hands of the developers and DevOps teams, who can only attempt to solve issues on a case-by-case basis. This leads to reactive measures and, by then, it’s often too late.
In response, many will say: “Train the developers!” But that is an inadequate shortcut. Security issues are generally not at the front of a developer’s mind. They have a different role, focused on fulfilling feature development and functional requirements. They do not have the full picture on the scope of security issues and can only offer lagging measures.
Developers typically identify a problem, and then look for the simplest and fastest solution possible. That is the patch-by-patch formula we want to move away from. Relying on developers to fix one issue at a time and on DevOps engineers to employ a niche tool for each type of threat will never create a sound architecture, and the status quo cannot provide the long-term security that businesses desperately need.
Shifting the mindset
The standard approach to security found across the business landscape is outdated and failing.
Security must be viewed as an organizational value that exists in all aspects of its operation and in every part of the product development life cycle. That includes planning, design, development, testing and quality assurance, build management, release cycles, the delivery and deployment process, and ongoing maintenance.
The new approach has to be both strategic and tactical. In strategic terms, every potential area of vulnerability has to be conceptually addressed through holistic architectural design. During the design process, tactical measures have to be implemented in each layer of the technology ecosystem (applications, data, infrastructure, data transfer, and information exchange).
Ultimately, the responsibility will fall in the hands of the development and DevOps teams to build secure systems and fix security problems. The strategic and tactical approach outlined will allow them to handle security successfully. Security policies must be applied into the product development life cycle right where code is being written, data systems are being developed, and infrastructure is being set up.
Watertight security
What must be done on a technical level?
First and foremost, protecting data needs to be a priority in the security strategy. A company should never have a monolithic database with data centralized in one location. It has to be segmented and distributed, so that the blast radius of a data breach is limited, with potential thieves only able to access tiny fragments of data.
For example, exposing credit card numbers without card-holder details creates a limited risk. Full credit card details getting compromised, however, may lead to a full-blown disaster. That dispersal is achieved by separating different types of data (and information): personally identifiable information (PII), protected health information (PHI), and financial data.
Another point of danger that must be accounted for is application programming interfaces (APIs). As they attempt to interface with an application, they need to be evaluated and secured. Here, network isolation control is required to allow different applications to interface with one another. It allows a security team to see how interactions are taking place between databases and how APIs are communicating with databases, by identifying them separately.
There are a couple of basic rules of thumb crucial to developing a watertight security architecture:
- Communication channels have to be encrypted. No one can expect constant vigilance from those using communication channels and at some point users will let their guard down and assume they are safe to share sensitive information. The only surefire way to protect sensitive information in the future is by having encryption built in.
- The code has to be impervious – or (more realistically) as close to that ideal as can be achieved. It must be subject to security and vulnerability tests. Every single commit of code must meet standards, with no exceptions.
Toward a practical solution
A typical company doesn’t have a single application – they have many, built over a number of years, by various people, creating a constantly changing landscape of technologies, infrastructure, and processes. To make matters more challenging, security awareness, policies, standards, and implementations are also constantly evolving.
The inevitable consequence is fractured architectures that become easy targets for hackers.
A watertight solution is one where a company designs a strong architecture which natively tightens every aspect of the ecosystem. In software, that can be accomplished through automation.
Cloud engineering automation platforms can do the work to migrate all existing applications to ensure they all comply to the same security standards. The DevOps team can then introduce phase gates to ensure that the policies are adhered to throughout the product development life cycle.
Security threats are not going away. A patch methodology, which can only defend against yesterday’s threats, must be abandoned. It is time to embrace a philosophy and strategy that covers all bases, and offers a robust defense for future, still unspecified threats.
There are automation mechanisms that can help ensure a smooth transition from a fractured architecture to a holistic architectural state. And with future attacks a virtual inevitability, time is very much of the essence.
