Security Governance, Risk, and Compliance (GRC) Management

Governance, risk, and compliance (GRC) management must always be involved in the software development process; otherwise, the released products provide liabilities that will be passed on to the company, its customers, and its shareholders. GRC refers to all the capabilities that integrate the governance, management, and assurance of performance, risk, and compliance activities. A common blind spot in GRC deployment in DevOps is the SDLC. Although standard GRC approaches have a way to go to complement DevSecOps and DevOps concepts, automated tools and appropriate processes and procedures are moving in that direction. It is crucial that GRC requirements (that include security requirements) are incorporated effectively into all DevOps automated and manual processes, which, of course, will include the entire SDLC, ideally built into the SDL. This will result in the ability to successfully pass audits and avoid regulatory fines.

In order for GRC to be a DevOps enabler rather than an obstacle, it must be able to adapt to the fast pace and highly Agile nature of the DevOps team. Conversely, the DevOps team must support governance, where regulations are constantly changing and evolving and new versions are either in the pipeline or will be introduced in the near future along with new compliance standards. This will require that the legal and compliance teams work closely with the developers to design and implement changes that satisfy risk and control points. This will require awareness and training provided or coordinated by the legal and compliance teams so that the developers can learn the rules and laws specifically governing their particular industry and collaboratively figure out how to implement their associated control points and software elements that will ensure compliance. This will typically require breaking down the same organizational communications silos that existed for security. If the DevOps teams are properly trained in GRC and empowered with the right technology, they will be a true asset with regard to technical vulnerability and threat management. Effectively incorporating security and other GRC measures, and automating them where possible into the development and operations processes, allows your organization to truly reap the maximum benefits of security and GRC.

In our programs, James and Brook have made use of a lightweight governance technique that fosters individual responsibility, while also providing reasonable governance to ensure that teams are, in fact, enacting the SDL. Rather than manual, in-person boards of experts, we have governance of the SDL that can be successfully accomplished through peer+senior review of task results. This has been particularly effective in governing the parts of the SDL that require significant experience to execute well, for instance, threat models. We present our current approach in Chapter 4, which is devoted to threat modeling and secure design. (The peer review and escalation model has already been discussed in Securing Systems (2015)’ and Secrets of a Cyber Security Architect (2019).+

Another area that is critical for both GRC and security is what we call “consequence management.” There must be consequences for both willful and mistaken violation of requirements that have been mandated by both organizations as well as course corrections identified to make sure this doesn’t occur

Schoenfield, B. (2015). “12.2 Some Thoughts on Governance,” Chapter 12. Securing Systems. Boca Raton (FL): CRC Press/Taylor & Francis Group, pp. 348-350.

t Schoenfield, B. (2019). “4.3.1 Nimble Governance,” Chapter 4. Secrets of a Cyber Security Architect. Boca Raton (FL): Auerbach Publications/Taylor &t Francis Group, pp. 90-92.

again. The severity of these consequences will be predicated on the potential or real damage to the company and whether the violation was willful.

In addition to the role of audits to conduct internal audits or bring in a third party to audit, to ensure compliance with regulatory requirements and standards, as well requirements to meet customer contracts, you can also use audits to help drive cultural changes. This is done with security when organizations encounter resistance to change the product to meet regulatory or customer security requirements or resistance to organizational changes required to support GRC and security. Given that the audit organization typically reports to the board, this usually fixes the problem.

Keep in mind that you can inherit your customers’ security requirements. This is particularly true with financial and government customers. This needs to be considered from a business and resource perspective when marketing and sales start pitching your products to these types of customers. For example, if your company decides to take on a customer that requires you become FedRAMP' certified, this may result in a significant amount of overhead to make sure you can meet things such as infrastructure; the ability to eliminate shared environments; meet personnel, citizenship, and clearance requirements; specific software and physical security requirements; and SLA requirements. FedRAMP stands for Federal Risk and Authorization Management Program and is mandatory for Federal Agency cloud deployments and service models at the low-, moderate-, and high-risk impact levels.

SDL and other related tools have supported GRC compliance checks for the last few years, but it has been a small market that has started to expand rapidly with the advent of DevOps. GRC collection, compliance, training, and management hooks are now embedded in the most popular SDLC frameworks tools.

Automated tools can help you achieve and maintain compliance with regulatory standards. These tools deliver a proactive and collaborative platform to effectively integrate tools, processes, and technology for compliance reporting; set thresholds for compliance like HITRUST, HIPAA, and PCI frameworks; and strengthen and improve regulatory compliance responsiveness to new change or risks:

One area of particular interest for automation is the Application Security Risk Threat Management (ASTRM). which is essentially GRC for DevOps. ASRTM complements but does not replace SAST, DAST, and interactive application security testing (IAST). Coupled with a solid foundation of security awareness training, ASRTM enables teams to systematically build and maintain secure software. ASRTM solutions have four major capabilities: threat modeling, requirements generation, Application Lifecycle Management (ALM) integration, and testing integration and aggregation.[1] [2] ASRTM vendors are still maturing, and it is important that GRC and security practitioners in a DevOps environment should keep a close eye on how they are managing applicable frameworks such as GDPR and NIST.

Another area of interest for automation is configuration management. Configuration management systems enable you to configure, update, and patch systems more efficiently and effectively. Their ability to address GRC challenges are often overlooked. Organizations have a set of policies by which they must abide, which include how the organization is to comply with legal requirements and relevant regulations or standards. Information is created and read by applications that run on servers accessing the data across networks and can be used to identify the connections between each of these components so that they can better understand the overall environment and use this information to address GRC challenges such as meeting specific compliance standards, for example, the Payment Card Industry (PCI) and Data Security Standard (DSS) for financial control systems. The resulting asset discovery information in the configuration management database (CMDB) has enough data on all elements of the hardware and software to enable admins to search for patterns and usage, which is also useful in combating GRC challenges. This is another area for GRC and security practitioners to keep an eye on.

The GRC, legal, and security teams will work closely to ensure the creation, updates, and compliance with the DevOps security policies. The purpose of a software security policy is to define what needs to be protected and how it will be protected, including reviewing and incorporating policies from outside the SDL that may impact the development process. These might include policies governing software or applications developed or applied anywhere in the organization. During this phase, any policy that exists outside the domain of the SDL policy is reviewed. Corporate security and privacy policies will likely instruct designers and developers on what the security and privacy features need to be and how they must be implemented. Other policies may include those that govern the use of third- party and open source software or the protections and control of source code and other intellectual property within and outside the organization. Assuming the software security group is separate from the centralized information security group, it is important that both groups collaborate on all policies and guidelines related to the development and post-release security support and response of software from that organization. It is also important to collaborate with the privacy function of the company, whether it is a centralized group or outside legal counsel.

The SDL also provides an invaluable guide for software developers setting a security standard for their organization and should offer a roadmap for implementation without disrupting the core business of producing quality software applications. This is another key area that the GRC and security team will collaborate on. Unless the senior leadership of the development organization and the management team support this model, the SDL will likely fail. It must be driven by a policy that is signed off, promulgated, and provides support by the software development management team and ideally by the CEO. An organization should have a documented and repeatable SDL policy and guideline that supports the SDLC, including its business needs and as a complement to the engineering and development culture that it supports. The culture and maturity of the organization are very important to consider in the development of the SDL policy, so that you ensure it will be both feasible and practical to implement. The management style, complexity of people, process, and technology needs, including the overall architecture of the product, will help determine how granular or objective in focus the guidelines will be. The amount of outsourced development, if any, will need to be assessed as part of this process as well. An internal development team will require more detailed procedures, whereas an outsourced function will require more contractual objects, service levels, and detailed deliverables.

  • [1] U.S. Government. (2020). FedRAMP Website. Retrieved from * Tauruseer. (2020). “Audit—Automate Compliance to Regulatory Standards.” Retrieved from
  • [2] Security Compass. (2020). “Introducing Application Security Requirements and Threat Management(ASRTM).” Retrieved from
< Prev   CONTENTS   Source   Next >