The structure in which security groups are usually constructed to respond and protect against cyber threats is highly flawed. The constant disconnect between where and how security policies are framed, security is enforced, and security is audited can be observed with meticulous scrutiny. While the integrity of security platforms is looked after and maintained by security officers, they are not the ones responsible for developing the security solution that protects the organizations.
Additionally, the responsibility of ensuring the system’s design and development is in complete conformance with the security policy and it does not fall upon them. That solely relies on the 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.
Train the developers – is the only response many will have but that is also deemed as an inadequate shortcut. The issues with security are generally not at the forefront of a developer’s thought process. Their role is different, one that is focused on fulfilling feature development and functional requirements. They do not have a complete understanding of the security issues and can only offer lagging measures.
When a problem is typically identified by a developer, they tend to offer a simple and fast solution. Usually, it is the patch-by-patch formula we want to move away from. Being dependent 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.
Changing the Ethos
Found across the business landscape, the standard approach to security is outdated and is prone to failure.
Security in true sense is nothing but an organizational value that exists in all aspects of its operation and in every part of the product development life cycle and that is how it should be viewed. The entire product development lifecycle includes planning, design, development, testing and quality assurance, build management, release cycles, the delivery and deployment process, and ongoing maintenance.
The new approach towards security should be both strategic and tactical. In strategic terms, every potential area of vulnerability has to be conceptually addressed through holistic architectural design. Tactical measures have to be implemented during the design process, in each layer of the technology ecosystem.
Conclusively, the responsibility will fall in the hands of the development and DevOps teams to build secure systems and fix security problems. The tactical and strategic approach, developed and adopted will enable them to handle security successfully. Right where code is being written, the security policies must be applied into the product development life cycle, similarly, where the data systems are being developed, and infrastructure is being set up.
Hermetic Security
On a technical level – what must be done?
First and foremost, in the security strategy protecting data must be of the highest priority. An organization should never build a monolithic database with their entire data centralized in one singular location. The data has to be distributed and carefully segmented to ensure the blast radius of a data breach is minimized, with potential thieves only able to access tiny fragments of data.
Another perilous point that should be addressed is the Application Programming Interface or the API. The APIs need to be carefully evaluated and secured as they make an attempt to exchange information with an application. Here, to allow different applications to exchange information or data with each other, network isolation is required. It enables security teams to monitor how interactions are taking place between databases and how APIs are communicating with databases, by identifying them separately.
There are few basic rules to developing hermetic security architecture:
- Encryption of communication channels is necessary. Constant vigilance cannot be expected and 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 way to protect sensitive information is by having built-I encryption.
- Impervious should be the definition of the code. It also must be subjected to vulnerability and security testing. No exceptions should be made and every commit of the code should meet the standards.
Paving the way for a realistic solution
A given organization has many applications constructed over a number of years, by various people, creating a constantly changing landscape of technologies, infrastructure, and processes. Making things more challenging is evolution setting in with security awareness, policies, standards, and implementations.
Inevitably they become easy targets for hackers by having fractured architectures.
An impregnable solution is one where the organization designs a strong architecture that natively tightens every aspect of the ecosystem. Automation can surely make it possible in software.
Migrating all existing applications to ensure they all comply to the same security standards, can be done by cloud engineering automation platforms. Phase gates can be introduced by the DevOps team to ensure that the policies are adhered to throughout the product development life cycle.
Security threats are here to stay. The patch methodology that can take care of threats of the past must be discarded. It is time to embrace a philosophy and strategy that covers all bases and offers a robust defense for future, still unspecified threats.
A smooth transition from a fractured architecture to a holistic architectural state can be achieved through automation mechanisms. Time is of the essence, with future attacks being anything but inevitable.
To read more, please check eScan Blog
