4.1.  General

Reflexive Security is an approach for information security management built upon the principles of Agile and DevOps. It is a non-prescriptive framework that is purely needs-based, emphasizes collective responsibility, and considers information security and its responses to be a holistic function of the organization.

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

Reflexive Security emphasizes security across organizational roles that reacts to external and internal threats in an agile and dynamic way. It aims to be a new information security management strategy that is dynamic, interactive, effective and holistic.

4.2.  Relationship with ISMS

Comparing to the traditional Information Security Management System (ISMS) approach, Reflexive Security aims to follow a similar spirit as Agile software development when compared to the Waterfall mindset.

Reflexive Security treasures dynamic information exchange within the organization. Like the immune system of the human body, information is immediately propagated to adjacent, potentially vulnerable functions given detection of a threat. A traditional ISMS approach is top-down: it requires threat information to be reported back to the higher functions, before any response can be made. In Reflexive Security, organization functions themselves are already integrated with security functions, and can provide an immediate response to address potential impact. A centralized response is important, but should not prohibit an immediate tactical approach.

The ISMS approach is about adopting best practices. However, often best practices that work in larger organizations do not work with smaller ones. In fact, they can create an unnecessary burden for smaller organizations, taking away precious time and effort and hence negatively affecting their information security stances.

Reflexive Security also alleviates the security skills shortage paradox by promoting the idea of “hybrid domain-security experts”, by delegating risks and security responsibilities to organization functions.

Top leadership commitment as required in an ISMS, while crucial, is insufficient. Top leadership has to understand the nature of information security and needs to be committed to integrating information security into each and every aspect of the organization. Top leadership must be themselves integrated into the information security function — fully understanding the risks and threats the organization faces (its risk profile) with regards to information security, setting clear bounds and requirements for personnel to adhere to.

The human link is often the weakest link in information security. Phishing, social engineering are all techniques to trick an unsuspecting individual to voluntarily compromise the security of an organization. Without full and active participation of the involved individuals, beyond awareness, information security simply cannot be achieved.

5.1.  General

The six pillars can be abbreviated into the acronym RAMPAC (Responsible collectively, Automate, Measure, Pragmatic, Align and bridge, Collaborate and integrate).

5.2.  Responsible collectively

Security leadership plays a shepherding role for information security within an organization. However, everyone is responsible for an organization’s security. Each individual has their own security responsibility, and they must be aware of their own contribution (and potential problems) towards the organization’s security stance. Edge users not only have to be security-aware, they are the first line of defence for the organization.

5.3.  Pragmatic

Security should provide value, not a hindrance. For every security initiative or adopted security control, a cost-benefit should be prepared demonstrating the value of security. Without a pragmatic approach, it is easy for persons unaware of the benefits of security to dismiss security practices as mere overhead or unnecessary. A pragmatic approach provides crucial information in building business case evidence to convince stakeholders of the importance of security, giving them confidence that plans will be executed faithfully.

The traditional ISMS approach relies on a best practices approach which could easily lead to overhead. Rarely are organizations not resource-constrained, and it is necessary to balance tailoring requirements to the organization against the adoption of best practices. Requirements must be based on organizational risks and value for maximum effectiveness.

5.4.  Align and bridge

Organizational risks and requirements must be fully aligned in order to derive maximum effectiveness and value from security processes. Security requirements that misalign with organizational risks represent resources potentially wasted, or worse, attention that has been taken away from critical matters that could cause organizational harm. By carefully aligning requirements throughout the organizational context, such as contractual, regulatory, product, security and compliance requirements, it is possible to extract maximum value by condensing a set of core requirements for the organization, allowing the delegation of risk management at more tactical levels for more dynamic responses and efficient usage of resources.

5.5.  Automate

Automated security practices are the core of optimizing process efficiency. Processes that can be automated should be automated, and those that can’t should be transformed. Automation also creates its own set of problems but automated approaches to those problems are often possible. A mantra in software development says, if one does the same thing three times, it will be time to program it. This approach applies squarely to Reflexive Security.

5.6.  Measure and improve

Performance that cannot be measured cannot be improved. Without measurements, there is no understandable evidence whether information security management is effective. Reflexive Security is about achieving results, and the results must be measurable for transparency and improvement.

5.7.  Collaborate and integrate

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 human factor is often the weakest link — most security incidents are caused by inadvertent human error. Security must be integrated into every aspect of business. Dedicated security personnel rarely have in-depth business domain expertise. No one else knows the business domain and its risks as well as those responsible for it. A team of dedicated security experts are likely oblivious of domain-specific security issues. Domain knowledge and security knowledge must be fused and co-exist in every organizational process for effective security management.

6.1.  General

The six benefits can be explained with the acronym HEARTY (Human-centric, Elastic, Apt and holistic, Resilient, Tailored, Dynamic).

6.2.  Human-centric

Security is integrated and internalized as an aspect of everyone’s work, and requires mind-share within every employee. It is not an external responsibility enforced or required by a separate, dedicated, security function.

6.3.  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. Its principles allow scaling according to organizational risks and needs, preventing permanent overhead in resource consumption.

6.4.  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, from business goals to operational processes to humans, who often turn out to be the weakest link.

6.5.  Resilient

Security no longer relies on a single security function, e.g. a single security department, but security practices are integrated with business processes and embedded throughout the organization. When compared to ISMS processes, an Reflexive Security approach often enables deeper security involvement amongst personnel, resulting in more resilient security activities.

6.6.  Tailored

Prioritized approach to provision stronger protection to core or more vulnerable processes over those less exploitable. The traditional ISMS approach often applies the same set of controls across all processes, leading to inefficient resource allocation.

6.7.  Dynamic

The protection of business goals is performed by integrating security with business processes, often down to the tactical level. This allows the organization to react faster and more effectively to threats and incidents.

7.1.  General

Reflexive Security can be considered as the amalgamation and integration of the DevSecOps, DevOpsSec and SecDevOps practices, placed within a holistic framework. These areas of practice all derive from the integration of security and DevOps principles, together with essential concepts from Agile.

Concepts made apparent by Agile software development practices (where “Agile” is the generic term including practices like Scrum), such as incremental development, collaborative authoring, test- or behavior-driven programming, and continuous integration, have given rise to infrastructure operation practices such as continuous delivery, software-defined infrastructure and infrastructure automation.

These infrastructure-related practices are widely considered to be part of the “DevOps” repertoire, but with several conflicting definitions of what exactly the term represents, it is necessary to clarify and standardize its definition in order to evaluate and address its information security impact¹.

Its practices can entail different processes and outcomes depending on organizational context. Its processes could provide organizational-wide benefits through empowering integration and interaction between development and operations (e.g., the “build” and “run” processes), or in some cases, have minimal impact in complex enterprise teams where logistics and governance controls limits the application of DevOps².

The application of Agile and DevOps practices and related tools clearly have blended borders between software development and service infrastructure automation. Information security management and operations can benefit from an identical approach, with even tighter integration since it already depends on both software development and infrastructure automation.

The practices of DevSecOps, DevOpsSec and SecDevOps, as described below, provide necessary insights for the achievement of Reflexive Security. The three major aspects of how Agile and DevOps principles can help achieve Reflexive Security for information security management are shown below:

7.2.  Securing DevOps practices

7.3.  Implementing security operations through DevOps

7.4.  Securing information security processes with DevOps

8.1.  General

This clause provides some guidelines for organizations for the implementation of Reflexive Security. The guidelines below are meant to be indicative, not exhaustive.

8.2.  Culture Shock

The goal of DevOps has been to write code and move product into production as fast as possible while maintaining a single source of truth, and removing or sidelining any barriers to their progress. The goal of security has always been too protect the organization internally and externally from access. Individually the goals are admirable until it gets to the point where DevOps deploys insecure software or security delays deployments to the point where the organization’s goals are affected.

Embedding Security into DevOps can be a shock to the traditional system. Plan to deal with the issues of DevOps and Security working closely with common goals and metrics. Plan for the personal effects of automation: changed, lost and or new positions.

8.3.  Cross-train

Form an operational security function by selecting key persons that have an interest or background in security from each team and delegate security related tasks to those individuals. Make these persons a representative of the operational security teams.

The operational security teams know exactly what types of operating systems are used, applications are supported for the business, etc. In some organizations, this collaboration involves embedding IT operations specialists within software development teams, thus forming a cross-functional team. This effort may also be combined with a skills matrix.

8.4.  Delegate

Delegate risk management, maintenance of BCPs etc. to department heads. Freeing up resources of the dedicated security team so they can focus on the security process management and providing the framework(s). The department heads know exactly what they have in house, what risks there are.

Reflexive Security is process neutral. Organizations can use Agile, Scrum or any other development methodology. Have security engineers attend daily scrum meetings, make them part of the team.

8.5.  Automate with purpose

One of the primary rules of DevSecOps is to automate early and often with the goal to embed security into the process but don’t try to automate everything at once. Select those areas that will address the greatest risk for automation first. Also choose your automation tools using a selection method including testing that reflects the specifics of your environment.