With the proliferation of cloud-based applications, organizations are faced with complex challenges regarding security as a whole and how to provide controls around the data that now resides somewhere in Neverland. We have moved away from the idea of the workplace’s four walls, complete with well-known kill chains, and find that our data is moving to the cloud at an alarming rate.
Perhaps the largest issue when moving to the cloud is trying to figure out how to secure applications, and users, without adding overhead and complexity. The cloud is supposed to make our lives easier while ensuring that the bad guys can’t get in. On the surface, this seems like an easy fix, especially when you think of it in terms of the existing security infrastructure. Unfortunately, reality sets in, and you begin to see this magical space rapidly becoming a logistical nightmare. How am I going to secure all this? Who is going to vet my users? What happens if an application is compromised, and allows a nefarious user to crawl my properties from east to west? How fired am I going to be at the end?
This is where the DevSecOps approach comes to the rescue. The whole premise of DevSecOps is around placing security controls within the applications themselves. In days gone by, things like admin credentials and cross-application access controls were hard-coded into apps. While this was business as usual for many years, it has increasingly become a highly available attack vector for hackers. When you combine this with known, and previously unknown, CVEs it becomes a glaring loophole in your security posture.
WHITE PAPER: On Your Mark, DevSecOps, Go!
The most common method for addressing pre-production security gaps is to have a human security specialist review the code, perform the STIG process, and apply various toolsets to identify and remediate vulnerabilities. The inherent problem with this process is that security staff are often overrun and facing long backlogs as the Dev team increases the speed at which apps are ready for deployment. Adding Sec to DevOps allows the developers to inject security into the earliest processes and, by doing so, creates self-healing, self-remediating applications that are fully aware of known exploits and continually updated to reflect novel threats in a fully-automated process.
The second problem hard-coded credentials can present is in app-to-app communication. As it stands today, a vulnerable application can be compromised, allowing bad actors to view dependencies, make changes, or otherwise gain access to additional properties, all while masquerading as an approved application. This becomes an enormous concern, as some of the database, app, and user calls could cross multiple applications and provide access to something that may not have robust security controls baked in. Mainframes may be out of vogue, but they are often the legacy central repositories for huge amounts of data, which may only have the ability to provide basic credential authorization. We’re left to rely on the legacy app, while the lift and shift to DevSecOps may not be feasible with today’s technologies. We must secure these apps.
In conclusion, these are some key points to take away for properly securing your applications and users as you move to the cloud:
- DevOps is falling to the wayside. You must look at holistic solutions to inject security as early in the CI/CD pipeline as possible.
- App-to-app security is paramount. If your applications cannot fully vet what it is talking to, it becomes open to compromise.
- Secure your cloud containers. This seems like a no-brainer but be mindful of your cloud architect’s time and workload, with the realization that posture management can be fully automated.
- Apply multi-factor authentication (MFA) to everything. Move security controls as close to the payload as possible. Network segmentation is great, but it allows vulnerabilities to be exploited.
