Agile cloud security was on stage at #RSAC2016 where I came face to face with its practitioners already living the solutions to problems some of our clients are only now discovering. My favorite sessions – from Javier Losa and Iñigo Merchán (BBVA) as well as Rich Mogull (Securosis) and others – recounted stories from the edge of agile cloud security, security-as-a-service (SECaaS), secure microservices, and secure DevOps orchestration techniques.
The Challenge
Cloud computing continues to challenge organizations. Only by leveraging advanced cloud services and scalable infrastructure in an agile manner can organizations can they compete or maximize effectiveness. Yet the same cloud advances promising productivity increase security pressures from cybercrime and regulatory protectionism.
As IT security professionals we all know these challenges. Shadow IT abounds, fragmenting the IT environment. Agile development and DevOps practices undermine existing assurance patterns. But we also know that large IaaS vendors provide high assurance platforms atop which we can develop robust cloud security practices and patterns. To that end, I’ve listed some of the core questions customers have been asking.
How can we develop or update our cloud computing strategy and what should it be?
“How can we develop a strategy” was already substantially addressed within the cloud security decision framework posts I wrote a month or two ago. These posts identify and explain 11 points on which clarity or decisions are required concerning the IT strategy to inform the security strategy.
“What should the cloud computing strategy be” is a more difficult question. The answers for any particular organization pivot on which vertical industry it’s in, and what’s its risk appetite. These factors may determine to what extent cloud computing should be adopted, and how fast and how tightly it should be controlled.
It’s also necessary to address some controversial questions (in the context of cloud) where reasonable arguments can be made on both sides. For example:
- Should the organization to use a single (or a few) CSP partners as much as possible, or should it use many best of breed solutions?
- Should business units have autonomy to select CSPs for their projects and/or should IT control what’s on the menu?
Once these management principles have been determined, it’s advisable to create a RACI covering the gamut of cloud management requirements. Gartner for Technical Professionals (formerly Burton Group) has created a cloud management toolkit around the ISO Plan-Do-Check-Act. At Security Architects Partners we’ve mapped similar lists of management requirements to the ISO 27001 framework.
How do we integrate the “shared responsibility model” into supplier management practices, security monitoring and development?
Although often the answer to the strategic questions on “how many CSPs” and “who decides” is “It Depends!” its still valuable to have the discussions at a high level of IT decision-making and formulate guidance or standards. This is because internal, managed service or public cloud providers organization’s select must, in many cases, be made to work together in a shared responsibility model. If they don’t you’ll find the paradox of insecure customer deployments atop robust IaaS CSPs.
Supplier management: IaaS or PaaS management is always a shared responsibility. Enterprises must know what’s in their contracts with CSPs, negotiate or purchase improvements and manage to what’s there. Technical management, though, boils down to three options:
- Buy cloud-native value added services (e.g. Amazon Key Management System (KMS)),
- Extend enterprise security infrastructure management services into the cloud (e.g. enterprise based key server or vulnerability scanner), or
- Utilize cloud security brokers (CSBs), such as Rightscale or Palerra, to simplify complex management challenges.
Security monitoring: The nature of usage, events, configurations and vulnerabilities in the cloud must be continuously watched. Some enterprise security information and event management systems (SIEMs) can download, aggregate and normalize logs from cloud services; some CSBs actually operate SIEM in the cloud.
Development: Some enterprise development teams perform development and testing in private clouds, or in separate areas of public IaaS. Others dispense with separate development and production clouds as much as possible as they adopt the DevOps model where development and operations groups are combined in one team and changes can be made to cloud services in place. DevOps brings us to the next question.
How can we integrate security assurance processes with agile development?
Working with clients, we’ve been seeing a disconnect between security organizations following a waterfall methodology, and development organizations following an agile methodology. The agile process lacks single requirements review, design review, code review, unit test and system test checkpoints typically employed for security signoff. Instead, security checks must be performed iteratively as each new use case (or user story) is developed and integrated into the system. This calls for static and dynamic code security reviews and other iterative steps to be automated so they can be done frequently – optimally by the developers themselves with reporting up to security and compliance.
How can we integrate security assurance processes with DevOps in dynamic IaaS environments?
Devops and agile methodologies often go hand in hand. Agile development gets a system into production quickly, DevOps ensure that agile developers can continue adding more “user stories” into the systems because these same developers are also the operators.
How does security get involved? Same as any other constituency. You have to add security stories (along with security frameworks and services) to the Pipeline. BBVA’s RSA presentation Security as a Service in a Financial Institution: Reality or Chimera? and few others (see related reading) provide lots of tips. Automate as much as possible, and turn the security steps on by default. Make the development of secure private or public cloud infrastructure and application planning, verification, orchestration, testing, scanning, monitoring, configuring and updating solutions themselves into agile DevOps projects so they can keep up. To summarize:
- Security requirements and design documents or sections should be embedded “into the Git” repository along with all other project documentation
- Automated static code scanning steps are performed every time new modules are moved into testing, and the output goes to the Jira issues lists or Bugzilla along with other discrepancies
- Security configurations are maintained in the instance or container manifests or recipies, and verified
- Dynamic code scanning is performed during system tests
- Security updating or patching is integrated with system and application maintenance orchestration, enabling health (i.e. patched or entirely new) instances or containers to roll into the cluster
Bottom line
The agile approach to cloud security isn’t a panacea, and it’s not for every project, but it will cover a good many low to medium risk use cases. I forgot to mention that for some scenarios penetration testing can’t be fully automated – as Javier Losa put it: “You need hackers as well as hacker stories.”
If that still isn’t enough assurance, one can always fall back on “bimodal IT.” Or maybe not. According to Laksh Raghavan, Paypal: “Our modern frameworks and apps built on those frameworks are inherently way more secure than our legacy stacks.”
Please comment: Could that be true, or do you think I’m drinking too much koolaid here?
More Recommended Reading
The post Discovering Agile Cloud Security appeared first on Security Architects Partners.