Introducing Reflexive Security for integrating security, development and operations

By the CSA DevSecOps Working Group 

Organizations today are confronted with spiraling compliance governance costs, a shortage of information security professionals, and a disconnect between strategic security and operational security. Due to these challenges, more and more companies value agility and integrated operations. In short, a security management program must now deliver more for less to match the needs of becoming cost efficient. 

How can organizations accomplish this task? In order to answer that question, CSA recently published a document defining Reflexive Security, a new framework that addresses today’s increasing risks and cybersecurity threats. 

Information Security Management through Reflexive Security — Six Pillars in the Integration of Security, Development and Operations 

This document provides a flexible framework that: 

  • Focuses on collaboration and integration 
  • Is outcome-oriented 
  • Provides a “reflexive” response to risks. 

The word “Reflexive” comes from the reflexive relation in mathematical sets, where every element in such a relation is related to itself. In Reflexive Security, every action taken is related to the context of the security at hand and needs of the organization itself. 

Reflexive Security versus ISMS

While the information security management system (ISMS) approach is well-defined by the International Standard ISO/IEC 27001, organizations who thrive with agile development or other collaborative-oriented processes have found it valuable to use the Reflexive Security framework. They value it for its non-prescriptive, holistic, needs-based, and interactive approach, especially with their existing activities that are already tightly-integrated. 

Reflexive Security builds on the examples from Agile development and DevOps movements, and is solely focused on a collaborative and integrated environment. It is especially suited for cloud environments, which are crucial for facilitating efficiencies for development and operation teams. Compared to the ISMS approach, Reflexive Security is like using Agile software development versus the Waterfall mindset. 

Reflexive Security also emphasizes security across organizational roles that reacts to external and internal threats. Similar to the body’s immune system, Reflexive Security values the balance of decentralization and centralization over a top-down leadership approach. This is so responsibilities and activities of information security management are infused to all members of the organization. 

The document describes the core principles of Reflexive Security in “Six Pillars,” which leads to the “Six Benefits,” and also explores a number of strategies for the fulfillment of this framework. 

The Six Pillars of Reflexive Security (abbreviated as “RAMPAC”): 

  • Responsible collectively: Security leadership plays a shepherding role for information security within an organization; everyone is responsible for an organization’s security.
  • Pragmatic: Security should provide value, not a hindrance.
  • Align and bridge: Organizational risks and requirements must be fully aligned in order to derive maximum effectiveness and value from security processes.
  • Automate: Automated security practices are the core of optimizing process efficiency.
  • Measure and improve: Performance that cannot be measured cannot be improved.
  • Collaborate and integrate: Arguably the most important Pillar. Security can only be achieved through collaboration, not confrontation. A security-aware and collaborative culture is necessary for everyone to feel comfortable reporting potential anomalies. 

The Six Benefits of Reflexive Security: 

  • Human-centric: Security is integrated and internalized as an aspect of everyone’s work, and requires mind-share within every employee.
  • Elastic: Growing maturity of a Reflexive Security approach could lead to achievement of formal ISMS requirements, while being flexible enough to only target critical areas for maximum value based on actual risks.
  • Apt and holistic: Focused on business needs and responding to the actual risk context faced by the organization when compared to traditional information security management.
  • Resilient: Security no longer relies on a single security function, but security practices are integrated with business processes and embedded throughout the organization. 
  • Tailored: Prioritized approach to provision stronger protection to core or more vulnerable processes over those less exploitable. 
  • Dynamic: The protection of business goals is performed by integrating security with business processes, allowing the organization to react faster and more effectively to threats and incidents. 

Key Takeaways

Reflexive Security is an information security management strategy that is dynamic, interactive, holistic, and effective. It represents cultural practices extrapolated from existing collaborative concepts and practices, and provides a set of widely implicating and easily understandable principles that affect an organization’s cybersecurity posture. This approach is especially suitable for organizations operating under resource and personnel constraints in today’s fast-paced and challenging cybersecurity landscape. 

Interested in learning more? Download this research report here: https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security/

“Shift Left” to Harden Your Cloud Security Posture

This article was originally published on Fugue's blog here.

By Josh Stella, Co-founder & Chief Technology Officer, Fugue

After a decade-long uneasy courtship with cloud computing, enterprises are migrating their IT systems to platforms like AWS and Azure as fast as they can. This means the key question for the security team is no longer “do we trust the cloud?” — it’s “can we trust ourselves in the cloud?” Answering “yes” requires embracing a term common in application developers circles: “Shift Left”. Just as developers unit test their application code prior to merging into the build, they should also implement automated unit security testing of their modules prior to merging into the stage environment. 

Small errors create big problems

If you’ve been running in the cloud at scale, you’re familiar with the challenge of trying to constantly monitor for the security risks created by resources without known owners, misconfigurations, and humans making errors like leaving too much access after a maintenance event. Human error is the number one cause of data breaches in the cloud, primarily due to the misconfiguration of cloud infrastructure. 

Asking the security team to monitor and address misconfigurations in real-time is asking them to tilt at windmills. They quickly become overwhelmed by alerts and struggle to keep up with manual remediation or an ever-growing bag of bespoke automated remediation scripts. The all-too-common result is that the organization finds its brand name and reputation splashed across news headlines and articles about data exposure or loss due to a cloud misconfiguration. 

Security and compliance shift left

Among developers, the term “shift left” describes moving a particular function to earlier phases of their processes to make identifying and fixing bugs and other errors easier and less time-consuming. The longer they wait, the more difficult making a fix becomes, and that creates delays. 

Developers typically relegate security and compliance considerations as afterthoughts implemented as a gate during the test phase. Then they grow frustrated when red flags go up that force them to perform rework in design, development, and testing, and blame the security team for delays moving applications into production.  

Automating the shift left of compliance and security into the design and develop phases will eliminate those delays and frustrations, make better systems, and turn those functions into highway builders rather than toll booth operators.

Establish universal policy interpretations and secure baselines

This isn’t just a process change, it’s a culture change. Organizations will likely need to get their security, DevOps and compliance teams to commit to establishing trust and confidence with one another. The best way to accomplish this is to have a “contract” between the teams in the form of actual code that includes explicit and shared interpretations of policy and establishes a baseline of the environment that is enforced via automated tools and processes all the way through the  software development lifecycle (SDLC).

A baseline is a complete configuration of an application from the infrastructure up. Baselining allows all stakeholders to determine if the configuration is acceptable early in the process. Developers need to make sure the system functions as intended. Operations needs to know that the system is reliable and maintainable. Security needs to know that it is configured in conformance with best practices and policies at deployment and during operations, and compliance needs to know that it meets audit and/or regulatory controls. 

By establishing a definition of known-good into the design and development phases, all parties can come to an agreement early in the process and work together to avoid costly delays. The term “DevSecOps” is becoming more popular as security and DevOps realize they need to come together to address security and compliance considerations earlier in the development process. Creating and enforcing a known-good baseline provides developers with real-time automated feedback through the design and develop phases so they avoid interrupts that breed delays and ensure that the production environment meets all security and compliance policies when deployed to the cloud.

Read more industry insights by the team from Fugue at their blog.

CSA Summit Recap Part 2: CSP & CISO Perspective

By Elisa Morrison, Marketing Intern, Cloud Security Alliance

When CSA was started in 2009, Uber was just a German word for ‘Super’ and all CSA stood for was Community Supported Agriculture. Now in 2019, spending on cloud infrastructure has finally exceeded on-premises, and CSA is celebrating its 10th anniversary. For those who missed the Summit, this is the CSA Summit Recap Part 2, and in this post we will be highlighting key takeaways from sessions geared towards CSPs and CISOs.

Can you trust your eyes? Context as the basis for “Zero Trust” systems – Jason Garbis

During this session, Jason Garbis identified three steps towards implementing Zero Trust: reducing attack surfaces, securing access, and neutralizing adversaries. He also addressed how to adopt modern security architecture to make intelligent actions for trust. In implementing Zero Trust, Garbis highlighted the need for:

  • Authentication. From passwords to biometric to tokens. That said, authentication alone is not sufficient for adequate security, as he warned it is too late in the process.
  • Network technology changes. Firewall technology is too restricted (e.g. IP addresses are shared across multiple people). The question in these cases is yes or no access. This not Zero Trust. Better security is based on the role or person and data definition. This has more alternatives and is based on many attributes, as well as the role and data definition.
  • Access control requirements. There is a need for requirements that dynamically adjust based on context. If possible, organizations need to find a unified solution via Software-Defined Perimeter.

Securing Your IT Transformation to the Cloud – Jay Chaudhry, Bob Varnadoe, and Tom Filip

Every CEO wants to embrace cloud, but how can you do it securely? The old world was network-centric, and the data center was the center of universe. We could build a moat around our network with firewalls and proxies. The new world is user-centric, and the network control is fluid. Not to mention, the network is decoupled from security, and we rely on policy-based access as depicted in the picture below.

Slide: Old World vs New World

In order to address this challenge, organizations need to view security with a clean slate. Applications and network must be decoupled. More traffic on the cloud is encrypted, but offers a way for malicious users to get in, so proxy and firewalls should be used for inspection of traffic.

Ten Years in the Cloud – PANEL

The responsibility to protect consumers and enterprise has expanded dramatically. Meanwhile, the role of the CISO is changing – responsibilities now include both users and the company. CISOs are faced with challenges as legacy tools don’t always translate to the cloud. Now there is also a need to tie the value of the security program to business, and the function of security has changed especially in support. In light of these changes, the panel unearthed the following five themes in their discussion of lessons learned in the past 10 years of cloud.

  1. Identity as the new perimeter. How do we identify people are who they say they are?
  2. DevOps as critical for security. DevOps allows security to be embedded into the app, but it is also a risk since there is faster implementation and more developers.
  3. Ensuring that security is truly embedded in the code. Iterations in real-time require codified security.
  4. Threat and data privacy regulations. This is on the legislative to-do list for many states; comparable to the interest that privacy has in financial services and health care information.
  5. Security industry as a whole is failing us all. It is not solving problems in real-time; as software becomes more complex it poses security problems. Tools are multiplying but they do not address the overall security environment. Because of this, there’s a need for an orchestrated set of tools.

Finally! Cloud Security for Unmanaged Devices… for All Apps – Nico Popp

Now we have entered the gateway wars …Web vs. CASB vs. SDP. Whoever wins, the problem of BYOD and unmanaged devices still remains. There is also the issue that we can’t secure endpoint users’ mobile devices. As is, the technologies of mirror gateway and forward proxy solve the sins of “reverse proxy” and have become indispensable blades. Forward proxy is the solution for all apps when you can manage the endpoint, and mirror gateway can be used for all users, all endpoints and all sanctioned apps.

Lessons from the Cloud -David Cass

Slide:

Cloud is a means to an end … and the end requires organizations to truly transform. This is especially important as regulators expect a high level of control in a cloud environment. Below are the key takeaways presented:

  • Cloud impacts the strategy and governance from the strategy, to controls, to monitoring, measuring, and managing information all the way to external communications.
  • The enterprise cloud requires a programmatic approach with data as the center of the universe and native controls only get you so far. Cloud is a journey, not just a change in technology.
  • Developing a cloud security strategy requires taking into account service consumption, IaaS, PaaS, and SaaS. It is also important to keep in mind that cloud is not just an IT initiative.

Security Re-Defined – Jason Clark and Bob Schuetter

This session examined how Valvoline went to the cloud to transform its security program and accelerate its digital transformation. When Valvoline split as an IPO with two global multi-billion startup they had no datacenter for either. The data was flowing like water, there was complexity and control created friction, not to mention a lack of visibility.

Slide: Digital transformation

They viewed cloud as security’s new north star, and said the ‘The Fourth Industrial Revolution’ was moving to the cloud. So how did they get there? The following are the five lessons they shared:

  1. Stop technical debt
  2. Go where your data is going
  3. Think big, move fast, and start small
  4. Organizational structure, training, and mindset
  5. Use the power of new analytics

Blockchain Demo

Slide: A simple claim example

Inspired by the cryptocurrency model, OpenCPEs is a way to revolutionize how security professionals measure their professional development experiences.

OpenCPEs provides a method of validating experiences listed on your resume without maintaining or storing an individual’s personal data. Learn more about this project by downloading the presentation slides.

The full slides to the summit presentations are available for download.

Deciphering DevSecOps


Security needs to be an integral part of the DevOps roadmap. Enterprise Strategy Group’s Doug Cahill shows the way

By Beth Stackpole, Writer, Symantec

Security has moved to the forefront of the IT agenda as organizations push forward with digital transformation initiatives. At the same time, DevOps, a methodology that applies agile and lean principles to software development, is also a top priority. The problem is the two enterprise strategies are often not aligned.

We recently spoke with Doug Cahill, senior analyst and group director at Enterprise Strategy Group, to get his take on the importance of the DevSecOps approach as well as how to retool organizations to adopt the emerging principle.

Q: Cyber security is often not an integral part of the DevOps roadmap. What are the dangers of such a siloed approach and what is the impact on the business?

A: Application development is now often being driven out of line of business, outside of the purview of centralized IT and cyber security teams. That’s because there’s a need to get new applications into production, or update applications already in production, as quickly as possible.

The risk of not having security integrated in a decentralized IT and application development approach is that there are too often no security controls applied. That means that too often new “code-as-infrastructure” is getting deployed into production for which security wasn’t contemplated at all.

Another problem is the use of default settings. Some basic examples are server workloads that are provisioned in the public cloud without going through a jump host or single proxy, which means they can be subject to being port scanned. Another common mistake is the lack of appropriate authentication controls; use of multifactor authentication (MFA) is something that a security practitioner would champion, but without security involvement in the DevOps process, it may not be thought about.

The risk to the business is as more application infrastructure becomes public cloud resident, we’re finding more of that is business-critical and sensitive. That exposes the organization to a variety of cyber security threats, both internal and external.

Q: Explain the schism between DevOps and cyber security teams that leads to siloed operations and failure to embrace more integrated DevSecOps practices.

A: It is really based in competing objectives. The AppDev and DevOps teams are chartered with moving quickly, getting new applications to production and updating those applications iteratively based on feedback from the market. Security, on the other hand, is chartered with making sure those applications behave in their intended state, meaning they are not compromised. Therefore, security professionals generally take a more deliberate, methodical approach to their job.

Security practitioners sometimes see DevOps akin to running with scissors—bad things happen when you move fast, from their perspective. DevOps, on the other hand, thinks security is just going to slow them down. In reality, there is a way to secure infrastructure at the speed of DevOps, so it’s a misunderstanding based on competing objectives. The gap can be closed, but the first thing is to understand that there is a gap.

Q: There’s a lot of talk about “shifting security left,” but also “shifting security right.” Can you explain what is meant by both and how it addresses integrated DevSecOps best practices.

A: The shift security left, shift security right metaphors are akin to the notion of having security bolted in versus bolted on. Traditionally, security has been bolted on; it hasn’t always necessarily been part of the design center. The world of continuous integration and continuous delivery (CI/CD) is really an opportunity to bake security into all environments and stages from development to test to production environments. We can think of shift left as pre-deployment and shift right as runtime. The notes to shift right is a reminder that we still have to apply runtime controls to those production servers and applications to protect them from intrusions. This includes things like appropriate access controls in terms of updating host-based firewalls, anti-malware controls, and anti-exploit controls.

Q: Why should a company integrate security processes and controls with DevOps?

A: There are a number of really compelling benefits to integrating security into the CI/CD pipelines, something sometime referred to as DevSecOps. One is the ability to secure at scale. Just as groups autoscale based on the capacity requirements of the application, security will be automatically integrated with the way you orchestrate and provision the new server.

Integrating security controls helps organizations meet and maintain compliance with regulations such as PCI and DSS as environments are provisioned and managed through the DevOps processes. It’s really about security and compliance at scale, but there is also a level of efficiency. If you can automate applying the right security controls based on the role of the server workload, it’s a highly efficient approach. There are so many corollaries in terms of project work—we know if we have to go back and do things later, it’s much less efficient than doing it right the first time.

Q: What is your set of recommended best practices for putting DevSecOps into action?

A: The best practices for DevSecOps are composed of people, processes, and technologies. If we take a page out of the shared responsibility security model that cloud service providers talk about, CSPs are responsible for physical security, network security, all the way up to the hypervisor. The customers are responsible for everything north of the hypervisor like the workload, operating system, applications, data, identity and access management. We should have a similar approach for the relationship between the DevOps team and the security team—both teams need to work collaboratively to secure public cloud infrastructure.

The second is to look at this as a risk management approach. In larger organizations, you’ll have multiple teams developing a wide variety of applications, but not all those applications have an equal level of risk to the business. If an organization is just starting down the DevSecOps path, they should start with one or two applications where they have the most risk for their business.

The next suggestion is to leverage the agile software development processes used to do CI/CD to write cyber security-related user stories. The cyber security team should partner with the product owner who is typically responsible for defining user stories and tasks that will be implemented over the course of the next sprint. The cyber security representative should really become part of the SCRUM team. They should be attending daily stand ups and explaining the value and importance of implementing these different user stories.

Q: Is there any sort of special ingredients that make for a DevSecOps-friendly culture?

A: I think it’s that security needs to be owned by everybody, and making security a requirement needs to come from leadership. You also need a dose of pragmatism—if an organization has a readiness gap and you’re playing catch-up, it’s taking a risk-based approach to identify where you have the most exposure and start there.

Security Risks and Continuous Development Drive Push for DevSecOps

How the need to speed application creation and subsequent iterations has catalyzed the adoption of the DevOps philosophy

By Dwight B. Davis, Writer, Symantec

curved steel bridge

The sharp rise in cyber security attacks and damaging breaches in recent years has driven a new mantra among both application developers and security professionals: “Build security in from the ground up.” Although it’s hard to argue with that commonsense objective, actually achieving it has proven to be far from straightforward.

Traditionally, of course, developers have focused on delivering reliable software that first and foremost provided the desired functionality. Security was largely an afterthought, if a thought at all – something that was to be layered on top of the application once it hit production. When, inevitably, applications were found to have code vulnerabilities, developers crafted and distributed patches to fix them.

Never ideal, the patch and update model has become untenable as security threats have escalated and software development cycles have accelerated. Much of this acceleration has been driven by public cloud computing, which has fostered the rise of a continuous integration/continuous delivery (CI/CD) development model.

At a more macro level, the need to speed application creation and subsequent iterations has also catalyzed the adoption of the DevOps philosophy. The fundamental basis for this movement is to better integrate developer and operations teams, thus ensuring that each side has a better understanding of the other’s needs and constraints.

By some estimations, DevOps and CI/CD can inherently aid in the creation of more secure software. Why? Because, thanks to the rapid application iterations, software flaws can be more quickly identified and more swiftly patched.

The problem with this supposed benefit is that it doesn’t alter developers’ build/patch mentality. Vulnerability fixes may indeed occur more quickly, but security still isn’t a core developer concern or responsibility.

Spanning the development & deployment cycle

To truly deliver on the “security from the ground up” objective, DevOps teams need to blend in a security component that spans the entire software development and deployment lifecycle. That need has resulted in the notion of a DevSecOps paradigm or culture. Here again, though, the concept is easier to grasp than to achieve.

The challenges associated with DevSecOps range from cultural to technical. Developers long disinterested in security issues need to change their mindsets and expand their skillsets. Development and security teams that have largely operated in their own isolated domains need to learn how to tightly collaborate. Developers who already have tools for code production and management now need tools for building secure apps. For their part development team managers need tools to give them visibility into the security of the code each developer is producing.

When it comes to implementing DevSecOps, there is no one-size-fits-all guidebook. Cloud native and more entrepreneurial firms may be able to mesh their developer, operations and security teams more quickly and easily than more mature organizations that must break down existing functional silos. Even though there will be a gradient in how tightly integrated the various teams become in different organizations, however, there is a fundamental need to move security beyond its own isolated domain.

“The goal is to decentralize and democratize security,” explains Hardeep Singh, cloud security architect at Symantec. “Having centralized security and decentralized development and operations is a recipe for disaster.”

Although developers must become more conversant and capable regarding security issues and approaches, the degree of their security expertise will vary considerably. Likewise, security pros typically aren’t going to become coding wizards. That said, each group needs to better understand the other’s worlds, and how the two must intersect.

Often, the security members within DevSecOps environments will set high level priorities and best practices, while the developers will be tasked with implementing them.

“You can’t expect app developers to know the best practices to secure IP data or to identify a SQL injection,” says Raj Patel, Symantec’s VP of Cloud Platform Engineering. “But you can train them on safe development practices and techniques.”

There may be some resistance among developers asked to take more responsibility for building secure code, just as some security experts may balk at bringing developers more fully into the security lifecycle process. Most often, though, these two groups are happy to share the burden of producing secure applications, since doing so not only reduces cyber security risks but also makes their own work lives easier.

DevSecOps can also drive a meeting-in-the-middle truce between the historical – and polar opposite – attitudes of developers and security pros. The bias of developers has been to say “Yes” to user requests, while that of security experts – prioritizing security over functionality and ease-of-use – has been to say “No.”

“In some ways, DevSecOps can be how security teams move to ‘Yes,’ because they’ve helped developers address security needs right from the start,” says Patel.