Many organizations are in the process of adopting an application modernization strategy. This means different things for different enterprises and usually contain some or all of these factors: (1) migrating an application from in-house data centers to the cloud; (2) re-architecting the application to leverage microservices; (3) major enhancements or rewriting existing functionalities to adopt to new requirements and become more cloud native.
At the same time, many organizations are embracing DevOps methodology and Platform Engineering disciplines that offer faster delivery, better resource utilization, self-service capabilities and increased innovation. DevOps and Platform Engineering speed up developer workflow by using processes such as automated testing and continuous integration (CI). In short, application modernization is about how to run the application in the cloud as natively as possible, while ensuring it meets the organization’s criteria including cost, functionality, compliance and security.
At Qarik, we help our clients move from Data Center Native to a Cloud Native operational model to grow their business while reducing operational costs and improving security. Qarik brings “Security in Mind Design” throughout each stage of the modernization and transformation journey. As new systems, tools and processes are designed and implemented, we ensure security and data protection is at the core. We embrace true DevSecOps, breaking down collaboration issues between Development, Security and Operations.
For an organization that was not “born in the cloud,” there could be hundreds if not thousands of applications requiring migration. The whole modernization and migration process will take time, but what does the journey for application security look like?
Security for cloud native applications needs to be present throughout the entire lifecycle as part of the organization's overall security strategy and implementation. In other words, we look at application security from a holistic perspective.
Let’s discuss four areas that if implemented correctly, will improve an organization’s security posture and make applications more secure. They are: cyber hygiene, compliance, DevSecOps and security operations.
Basic Security
Basic security, sometimes called cyber hygiene, is a term that applies to cyber defense. According to the Center for Internet Security (CIS), the majority of successful attacks result from conditions that could reasonably be described as poor hygiene. For example, the failure to patch known vulnerabilities in a timely manner; poor configuration management in the cloud; poor management of administrative privilege; and non-human accounts. e.g, service accounts.
CIS critical security controls, (currently on version 8) are a reasonably good starting point. There are 18 controls and CIS created CIS Controls Implementation Groups (IG1, IG2 and IG3) as the recommended new guidance to prioritize implementation. Specifically, CIS have defined IG1 as “essential cyber hygiene,” the foundational set of cyber defense safeguards every enterprise should apply to guard against the most common attacks.
As an example, how would control 1.1, Establish and Maintain Detailed Enterprise Asset Inventory, be implemented in practice? In Google Cloud Platform (GCP), it could mean deciding how to apply labels and tags for resources and making use of either a cloud native asset inventory tool and/or to enhance the existing Configuration Management Database (CMDB) . Control 7, Continuous Vulnerability Management, and control 16, Application Software Security, are directly relevant for application modernization.
Organizations can adopt benchmarks such as their Google Kubernetes Engine (GKE) Benchmark and implement their GCP organization policies as well as ensuring the developers use Infrastructure as Code (IaC) to adhere to the policies.
Another source for basic security is Cloud Security Alliance (CSA) Cloud Control Matrix (CCM), which includes a number of controls including Application and Interface Security.
Regulatory and Compliance
Organizations are subject to regulatory and compliance requirements. It could be General Data Protection Regulation (GDPR), California Privacy Rights Act (CPRA), Payment Card Industry Data Security Standard (PCI), or Health Insurance Portability or Accountability Act (HIPAA). In certain industries, there may be specific compliance requirements down to the application level. For example, data privacy is a key requirement for any application that uses or processes data. In addition, organizations often have internal compliance requirements.
As part of the “production readiness” checklist, if there is a lack of security controls, or lack of compensating controls, applications cannot go live. A few items on a security to-do list in this category include:
Requirements are clarified, captured and entered into product backlog
Identify tools (e.g. Monitoring/Visibility) and what data feed they need
Documentation that is fit for regulators and external readers
In addition, a point of contact should be nominated to handle all internal and external security compliance questions.
DevSecOps & SecDevOps
DevSecOps is a software development methodology designed to bring development (Dev), security (Sec), and operations (Ops) together on a single unified team. SecDevOps is a process that aims to place security first in the software development and deployment lifecycle. Today, security is everyone's responsibility in the organization. We need to shift the attitude of the project team by raising security awareness across all levels and implement security measures/controls throughout the project, down the relevant agile sprints.
There are different phases depending on the organizations. In one approach, the phases are: pre-commit, commit, acceptance, production and operations. Another way to look at those phases is : develop, distribute, deploy and runtime. Some of the relevant generic security controls include:
Threat Modeling: depending on the applications, either a full modeling exercise (e.g. STRIDE) or some Rapid Risk Assessment should be performed
Peer Code Review: this is often a mandatory check
Static code analysis and dependency management
Security tests as part of unit and acceptance tests
Secret management and hardening
OWASP Top 10 CI/CD security risks
Threat intelligence and continuous monitoring
If the application runs on Kubernetes for example, there are specific controls and checklists to consider:
OWASP top 10 web application and top 10 API security risks. API is an increasing attack vector especially for microservices.
OWASP Kubernetes Top Ten
Linux foundation Kubernetes security checklist
MITRE ATT&CK container matrix
When possible, adopt a security approach that works for multiple applications. For example, mandate certain types of logs to be enabled whenever a CloudSQL database is used in an application.
Operationalize the Application and Security Operations
The team has implemented all mandatory requirements, completed acceptance testing and we are at the last sprints of the current phase of the project. Are we ready to go live in the cloud with our application that previously ran in our data center?
Many organizations have the equivalent of an Operations Readiness Review, a checklist that requires cross functional teams to satisfy before the application goes live. For security readiness, there should be an opportunity to verify either during the User Acceptance (or Quality Assurance) phase or soft launch phase. A few examples of checklist if the application runs on GCP:
Do we have GCP organization policies that can prevent/detect basic requirements (such as only using internal IP addresses)?
Are relevant logs sent to the observatory platform (e.g. Security Information and Event Management)?
Does the Security Operation Center (SOC) team have playbooks and know what to do for alerts related to this application?
Do we have an Incident Response plan?
A key aspect of cloud and application security in the response phase is the ability to perform auto-remediation. On a high level, this means the various security controls could take actions on threats without user intervention.
Beyond the first launch, releases may come frequently for this application. There needs to be a good feedback loop and blameless postmortems that will benefit the developers to improve application security posture.
Summary
Years of experience have taught us that the integration of security staff, process and tools into the application modernization process is fundamental to its success. That’s why Qarik’s approach actively seeks buy-in at every stage. Security staff need to appreciate and understand how developers work to ensure that security user stories are implemented and tested. We also secure vocal support from management that security is everyone's responsibility to ensure its frictionless implementation.
To accelerate your team's security approach, get in touch.