devopsy.kinsta.cloud

Tag: regulations

Eclipse Foundation Publishes Toolkit to Simplify CRA Compliance

The Eclipse Foundation today launched an Open Source Compliance: Comprehensive Techniques and Essential Tools (OCCTET) project specifically designed to help smaller organizations comply with the Cyber Resilience Act (CRA) enacted by the European Union (EU).

Scheduled to take effect by September 2026, the CRA defines a mandatory set of cybersecurity requirements for all digital products, including software, sold in the EU, that apply to manufacturers, software vendors and maintainers of open-source software projects.

The OCCTET project is creating a toolkit that includes a CRA compliance checklist, conformity assessment specifications, automated evaluation methods and tools, a federated database for publishing assessments of open source software components, inventories of automatic dependency analysis tools, and a reporting tool for generating documentation and evidence. At the same time, the Eclipse Foundation last year set up an Open Regulatory Compliance (ORC) Working Group, which today also revealed that Microsoft, Red Hat, ekxide, GitHub, Google and Open Source Matters have now also joined. In total, the ORC Working Group now has more than 50 member organizations, including Nokia and Mercedes-Benz.

The overall goal is to make it simpler for organizations, despite how executives may feel about, achieve and maintain CRA compliance.

Thabang Mashologu, vice president of community and outreach for the Eclipse Foundation, said the OCCTET project, in addition to streamlining compliance workflows for smaller organizations, can also serve as a framework for larger organizations that will eventually require a more comprehensive framework of their own. In the meantime, however, organizations of all sizes should be cognizant of the simple fact that they now have little more than a year to achieve CRA compliance, he added.

Less clear is the degree to which CRA might prove to be the foundation upon which all other compliance frameworks might be based. Given its current scope, organizations that achieve CRA compliance should be able to more easily comply with most any other set of requirements that might be applied in other countries or a highly-regulated industry. In fact, this is not the first time that a regulation defined by the EU winds up being the de facto foundation upon which workflows around the world are based, simply because organizations generally prefer to keep business processes as consistent as possible from one region to another.

Of course, each organization will need to determine to what degree CRA requirements might force them to abandon operating in Europe because regulations have become too onerous. Hopefully, however, CRA will improve the overall state of cybersecurity by raising the compliance bar. After all, far too many organizations still only seek to achieve the bare minimum level of cybersecurity and resiliency required by regulations that might apply to them. Those same organizations, of course, more often than not are likely to be victimized by cybercriminals that usually have a much keener appreciation for the limitations of existing compliance regulations.

Ultimately, each organization will need to determine for itself to what degree CRA requirements might apply to them, but at the very least, there is now a requirement that, hopefully, in the age of artificial intelligence (AI), will continue to become easier to achieve and maintain.

August 14, 2025
From Reaction to Robots: Riding the AI Wave in 2024

As we navigate another year of consistent zero-day breaches, legislative pivots, the explosion of AI tooling and threat actors growing bolder and more desperate, it’s safe to say that getting comfortable with change is a requirement for thriving in the technology industry.

We occupy a notoriously unpredictable space, but that’s half the fun. Compared to many other verticals, technology—especially cybersecurity—is relatively youthful, and the future should be something we can all look forward to blossoming in sophistication alongside the technology we swear to protect.

So, what can we expect in the industry in 2024? We put our heads together, looked into our crystal ball, and these were the results:

Government Regulations Around AI Will Turn the Industry Upside Down

It was the talk of the conference circuit in 2023, with several high-profile presentations at Black Hat, DEF CON, Infosecurity Europe and many more warning of the explosive changes we can expect from AI implementation across every industry, especially cybersecurity. As tends to happen with low barriers to entry for such transformative technology, adoption has outpaced any official regulation or mandates at the government level.

With significant movements in general cybersecurity guidelines and benchmarks around the world, including CISA’s Secure-by-Design and -Default principles in the U.S. and similar initiatives from the UK and Australian governments, it is essentially a foregone conclusion that regulations around AI use will be announced sooner rather than later.

While much of the debate surrounding the mainstream use of AI tooling and LLMs has centered around copyright issues with training data, another perspective delves into how AI is best used in cybersecurity practices. When it comes to coding, perhaps its most human quality is its similar hardship in displaying contextual security awareness, and this factor is deeply concerning as more developers are adopting AI coding assistants in the construction of software. This has not gone unnoticed, and in a time of increased scrutiny for software vendors adopting security best practices, government-level intervention certainly would not surprise.

… And Demand for AI/ML Coding Tools Will Create a Need for More Developers, not Less!

Much has been written about the AI takeover, and for the better part of a year, we have been subject to a plethora of clickbait headlines that spell doom and destruction for just about every white-collar profession out there, and developers were not spared.

After months of speculation and experimentation with LLMs in a coding context, we remain entirely unconvinced that development jobs are at collective risk. There is no doubt that AI/ML coding tools represent a new era of powerful assistive technology for developers, but they are trained on human-created input and data, and that has rendered the results far from perfect. Perhaps if every developer on the planet was a top-tier, security-minded engineer, we might see genuine cause for concern.

However, just as the average adult driver vastly overshoots their ability (notice how everyone says they’re a great driver, and it’s always other people who lack skill? That’s a classic example of the Dunning-Kruger effect!), so too does the development community, especially when it comes to security best practices. According to one Stanford study into developer use of AI tooling, it is likely that unskilled developers using this technology will become dangerous. The study claimed that participants who had access to AI assistants were more likely to introduce security vulnerabilities for the majority of programming tasks yet also more likely to rate their insecure answers as secure. This poses a significant issue; poor developers will be enabled to introduce security issues faster, and if anything, this will only increase the need for security-skilled developers with the knowledge and expertise to code securely and use AI technology safely.

We Will see Consequences for Software Vendors who Don’t Ship Secure Code

CISA director Jen Easterly has made it abundantly clear that software vendors should not be permitted to “pass the buck” when it comes to security within their products, highlighting that the current responsibility for software safety is largely passed to the consumer.

We have agreed with this view, and we believe it will take a shakeup of this magnitude to move the needle toward code-level security—not to mention appropriately educating developers—to be taken seriously.

While CISA’s powers only extend so far—essentially, they can only enforce secure-by-design practices to vendors that sell to federal agencies—this still presents a new security benchmark to hit for many large software vendors. Colonial Pipeline, SUNBURST and, more recently, the MOVEit data breach are all large-scale cyberattacks that affected government-level systems at some point, and with these new guidelines in play, there is a real possibility that future highly visible breaches will receive greater scrutiny and reprimand.

Reactive Security Will Start to be Seen as Old-School

As the goal of increased cyber resilience continues to dominate cyber strategies across multiple verticals, those who rely on reaction and incident response as the only core tenets of their plan will find themselves in a place of unacceptable exposure and risk.

Security professionals must act swiftly in the face of adversity and outright attack, but modern times call for modern solutions, and we simply cannot afford to take a less-than-holistic approach. “Shift left” needs to be more than a rapidly aging buzzword; code-level security should be prioritized, alongside upskilling and verifying the competence of the developers working on the software and critical digital infrastructure we take for granted. After all, who wants the security program equivalent of an Etch-a-Sketch when they could have an iPad Pro?

Now, more than ever, governments and enterprises alike must commit themselves to a preventative, high-awareness security program in which every member of staff is enabled to share responsibility. It’s not enough to cite the cybersecurity skills gap as a reason for falling behind; investment in security-aware developers and fostering collaboration between them and their AppSec counterparts should be a driving force in remaining as secure as possible, both as an organization and within the production of software.

Matias Madou, co-founder and CTO at Secure Code Warrior, contributed to this article.

January 10, 2024
Overture Maps’ Challenge to Google ¦ Frontier Model Forum’s AI Safety Shtick

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: A big-tech consortium goes toe-to-toe with Google Maps, and a big-tech consortium tries to fool AI regulators. (more…)

July 27, 2023
Chef Achieves Multiple Compliance Mandates

Chef today announced it will make it easier for organizations that adopt its IT automation framework to stay compliant with mandates such as the Federal Information Processing Standards (FIPS), Secure Technical Implementation Guidelines (STIG) and the Center for Internet Security (CIS) certification.

John Snow, senior software development engineer and federal content lead for solutions engineering at Chef, said it’s incumbent on the provider of an IT platform or application to make sure their offerings comply with widely required mandates. FIPS compliance, for example, not only applies to federal agencies, but also any organizations that interacts with those agencies.

Specifically, Chef said it has achieved FIPS compliance along with providing an implementation of STIG profiles for RHEL 7 and Windows Server 2016 in Chef InSpec and achieving a (CIS) certification for Amazon Web Services (AWS) Foundations Benchmarks Level 1 and 2 in Chef Automate. Chef claimed it is the first vendor to achieve CIS certification across AWS, Microsoft Azure and Google Cloud Platform.

Snow said Chef was able to achieve that goal in part because of the time and effort it put into developing a parser that enabled the company to approach compliance as a programmable extension of its development process. That translation process is required because most compliance mandates are written for auditors by auditors, not by IT operations teams. Chef will also leverage that capability to ensure its platforms remain current with any future updates to the compliance mandates its supports, said Snow.

Chef has been making a case for treating compliance as code for several years now. Any given compliance mandate typically consists of a set of controls that need to first be put in place and then tested and validated. Rather than trying to achieve that goal relying on manual processes that don’t scale, Chef contends achieving compliance should become a natural extension of best-in-class DevOps processes.

It’s not clear yet to what degree compliance may become integrated within DevOps. But recent advances in DevSecOps suggest it’s only a matter of time before responsibility for implementing compliance controls “shifts left” along with security control. Compliance teams may define what controls will need to be put in place. But responsibility for implementing those controls as part of any quality assurance process is moving toward DevOps teams. Developers, however, will take on that responsibility only when a means to programmatically implement those controls is readily available.

The long-term economic implications of that shift may prove to be profound. Organizations of all sizes incur massive costs both implementing compliance controls and having them audited by a third party. As the compliance process becomes more automated, not only does it become easier to implement controls at scale, but the documentation required to pass an audit is generated automatically. Given that most auditors charge per hour for their services, the savings derived from limiting the time and effort associated with preparing for and then passing an audit could be substantial. The challenge and opportunity is educating the DevOps team on not just how much money might be saved for the company, but also how much of that money might be reinvested in advancing DevOps adoption.

— Mike Vizard

March 13, 2019
How DevOps Helped One Firm Get GDPR Right

There has been a lot of press about how many, if not most, enterprises are still unprepared to comply with the European Union’s (EU) General Data Protection Regulation (GDPR) just days before it takes effect.

However, executives from Cybric, a security platform provider, said their company has been ready for some time—and they thank DevOps for that. Their case study also shows how firms that are still struggling to get started before GDPR takes effect can do what is necessary as they integrate compliance with their operations.

As soon as GDPR appeared on Cybric’s radar screen more than a year ago, the firm began to prepare. GDPR quickly became a compliance and data management process discussed among others on a regular basis and, as part of its DevOps, it involved the participation of all the stakeholders involved.

“One core part of the culture of DevOps is about collaboration, sharing and communications and making sure you have automated processes in place,” said Mike D. Kail, chief innovation officer at Cybric. “That is, in part, how we were able to do what had to be done for GDPR.”

Standard Procedure

Before GDPR was announced, Cybric already had its data flow management processes in order, Kail said. This included keeping transparent records of data sources and the corresponding geographic locations of the individuals in the databases. “We were already analyzing how we processed our data and knew where it was going,” he noted. “We were also always looking at all the ways we could automate how we handled data flows.”

The different infrastructure, development and business teams, of course, have also played a collaborative role in Cybric’s data flow management processes and resulting GDPR compliance. “Each team figures out how they how they can help, which goes back to the collaborative culture of DevOps,” Kail said. “It’s everybody’s responsibility and not just one team’s concern in the company. In the case of GDPR, the fines and levies can be significant, so everybody should take this seriously and not put it off and say ‘that’s not my problem.’”

In this way, Cybric was in a position to respond to the demands of GDPR compliance long before the deadline.

“One result of DevOps is you always take care of where the data is and how it’s being processed in an automated way,” Kail said. “The wrong way consists of manual, out-of-bound efforts for processes and tasks that people ultimately screw up or forget to do on a regular basis. And when that happens, you now have potential compliance issues.”

GDPR’s Long Arm

Some firms may be led to believe they are not concerned by GDPR if they do not store customer data from European customers. What they may not realize is that any data—whether it’s personal data for vendors, sales leads or general third-party business contacts for individuals based in a EU country—is protected by the GDPR mandate.

Cybric, for example, outsourced its customers’ personal data. However, the firm still must comply for individuals who visit its website and submit personal information to download marketing collateral.

“I think marketing is an area that a lot of people don’t think about too much,” Kail said. “They are like, ‘I don’t have any personal data directly,’ but indirectly, they do have personal data and must be GDPR-compliant.”

Many organizations have not yet prepared for GDPR since they have not fully understood the regulation and whether it applies to them or not. But although some of GDPR’s terms are opaque, organizations still should not delay compliance just because they do not completely understand what is involved. “I think a lot of people are trying to delay their compliance even though the GDPR deadline is just three weeks away,” Kail said. “And sadly, their databases are just not ready since they have not thought about the complexity of GDPR compliance and certainly not in a DevOps way.”

Small-to-medium-sized enterprises should also not be concerned about having to invest a disproportionate amount of resources to become compliant compared to what large firms will have to spend. Cybric’s small size—with fewer than 20 full time employees—has actually played to its advantage, Kail said. Additionally, Cybric’s story offers a look at how a small-to-medium-sized enterprise can use DevOps for GDPR.

“As a small company, putting together a collaborative process with all of the different departments made it much easier for us,” Kail said. “That is also the approach people have to take.”

— B. Cameron Gain

May 7, 2018
DevOps to the Rescue as GDPR Deadline Looms

The stakes are high: Organizations failing to comply with the European Union’s (EU) strict General Data Protection Regulation (GDPR) face fines up to 4 percent of their annual revenues or €20 million ($25 million), whichever is greater.

But while the threat of what happens if organizations ignore the mandate when it takes effect at the end of May is clear, how DevOps teams will lay the groundwork to comply is less cut and dry.

At the same time, DevOps can allow organizations to meet the regulation in an agile and relatively quick way by integrating the working efforts of an organization’s stakeholders, IT operations, QA, InfoSec and development teams.

“GDPR is the new boogeyman in tech, kind of like Y2K was years ago,” said John L. Myers, an analyst for Enterprise Management Associates (EMA). “Ideally, all of this will be handled with automation and DevOps.”

The Right to Disappear

An especially strict GDPR provision is any individual user’s right to both opt out of having their data collected by a private enterprise as well as their right to be forgotten. The so-called “Right to Erasure” Provision gives EU-based individuals the right to demand the removal of access to their personal data on an organization’s servers, either on-premises or the cloud. An individual’s right to have personal data “forgotten” also applies to personal information an organization may communicate to third parties.

“The challenge lies with tracing personally identifiable information spread across multiple platforms, including third parties and CRM, ERP, payments, ordering, etc.,” Myers said. “Most organizations don’t have that level of visibility and transparency.”

The challenge is thus understanding where all the instances of a person are within a data landscape, he said. If an individual in the EU decides to be forgotten and to opt out, an organization must know all the places where that person is identified within data management platforms and files, such as spreadsheets. For organizations that have a relatively small number of places where they store data, the process is easier, of course.

However, there is one important footnote in the right-to-be-forgotten provision: Organizations do not have to actually delete personal data and records if individuals choose to be forgotten, Myers said. Rather, DevOps can encrypt their information, allowing organizations to keep transactions, customer counts, inventory, etc., but without identifying the individuals. DevOps also can be used to rapidly deploy code and processes to validate requests to be forgotten and to “unforget” individuals who later opt in.

“With encryption, DevOps keeps one key for the company and sends or stores the other key for the EU individual in case they change their mind,” Myers said.

However, using DevOps to automate compliance might be delayed in some cases, as organizations may first have to improve their data inventory management practices to better visualize the often-various places where individuals’ data is stored, Myers said.

“Without an inventory of all the ‘wheres’ of customer, partner or supplier data that might be listed in the various data platforms, it will be difficult to automate out of the gate in May or even June,” Myers said. “As organizations get a better understanding of the inventory of their data landscape, they can add DevOps automation to the process. But at the earlier stages, it might be a manual process that is monitored, managed and standardized so that DevOps can take over and make it a reality.”

Some Good with the Bad

Discussions about GDPR tend to focus on the associated pain and potential costs organizations face to meet the mandate. But with every change comes opportunity. With respect to the GDPR clause giving individuals the right to be forgotten, for example, DevOps will have the freedom to deploy code and processes to boost their organization’s transparency for individual data storage, both in-house and what third parties access.

“Having this inventory or visibility into all the components of a data landscape is a key for digital transformation,” Myers said. “Companies can use it as a good reason or excuse to move toward a more standardized and transparent environment that will accelerate those initiatives.”

Some DevOps team members may also take pride in knowing achieving compliance for GDPR could also arguably be a step in the right direction to improve data protection for the common good of society.

“There is the issue with actually securing the data that is collected to keep others from obtaining and exploiting it. Since identity theft is a raging problem, protecting personal information is paramount,” said David Monahan, an EMA analyst. “If we had usable federal legislation in the U.S. like GDPR, we would have had a much likelier outcome of Equifax being severely fined or even closed down for its poor data-protection practices. Credit bureaus are predatory when it comes to data, and since individuals have no right to refuse collection, all of that information is bought and sold without our consent.”

— B. Cameron Gain

April 12, 2018
How DevOps Startups Can Deal with GDPR in 2018

Data protection is not a new issue. There have been numerous high-profile data hacks in recent years, with sensitive customer information released into the public domain, causing widespread condemnation and fury. Trust is a big issue. When Equifax revealed hackers had stolen the personal information of 145 million people, there was an uproar. The problem is that we are increasingly moving our lives online. Criminals have been quick to realize that data equals serious money. For this reason, DevOps startups need to pay close attention to the new GDPR data privacy regulation changes that are set to come into effect May 25.

What is GDPR?

The General Data Protection Regulation (GDPR) is an EU Data Protection Directive. It has been carefully designed to shape the way businesses deal with data privacy and has been described as “the biggest change to data protection law for a generation.”

The new directive will apply to all startups and businesses operating in the EU, and any company that holds data related to EU citizens. So, if your CFD trading startup is based in the United States, but you retain data on customers who reside in France or Germany, you are bound by the GDPR.

Data compliance is a huge issue. Cyberthreats are common and criminals are happy to take advantage of businesses that have left a backdoor wide open. Secure data management is not something DevOps startups can ignore. Any data stored in the cloud or on a server must always be protected.

Many tech startups hold significant amounts of information. This helps them deliver a software solution more effectively. However, even if your company holds no customer data, if any of your development team are EU citizens you still must adhere to the regulations. And with many DevOps startups recruiting remote employees from far and wide, this is not as unlikely as it may first appear. So, if Carlos from Barcelona is a key player on your development team, GDPR will apply to your startup.

Company and Customers

GDPR is split between company data and customer data. For a small startup, it may be a case that employee data is more of an issue, but if you hold customer data, it is time to look at how you manage this data. A good way to do this is through an internal audit.

Create a data flow diagram (DFD) that maps all the data that enters, is processed and stored and exits your systems. Provided with a good overview, you should be able to spot any data that isn’t required or needs modifying so you can remove or adapt certain funnels to save time attempting to meet compliance measures for data you don’t use.

Planning and Preparation

GDPR is a big step up from the Data Protection Act, so you can’t sit around and wait for May 25 to come and go. It’s vital that you examine the GDPR in detail to see how and if it applies to your organization. If it does, you will need to make organizational changes to the way you deal with data.

Create a compliance checklist to be adequately prepared, based on the requirements from the National Institute of Standards and Technology (NIST) and Cloud Security Alliance (CSA), combined with any state or regional regulation.

Hire a Governance Trainer

Legal language used in compliance can be difficult for those from an engineering and IT background to comprehend. Hiring an external compliance by design practitioner or trainer will help in this respect. Ensure they have a good technical as well as legal knowledge so that they understand both sides and are able to accurately review processes, make suggestions and make sure that GDPR compliance is met.

Task this person with downloading the Control Objectives for Information and Related Technologies and CSA requirements. They can then work with program management to put such company directives into play, alongside working with your checklist. This checklist can be used to create an open source tool for scrubbing applications and determining whether they should be onboarded or pushed back, depending on whether they meet the compliance policies.

Notifying Employees/Customers of a Breach

If customer or employee data is breached, accidentally or otherwise, you have 72 hours to notify them. Sticking your head in the sand and hoping it all “goes away” will not cut it. There are two tiers of fines for non-compliance: up to 10 million Euros or 2 percent of turnover, or up to 20 million Euros or 4 percent of annual turnover.

To ensure this risk is minimized, hold everyone accountable and put in place consequences. Decide on what these will be and how they will be enforced to best implement GDPR compliance in your startup, as such hefty finance can be especially damaging for small businesses.

Data Consent

You must let individuals know if their data is collected. Consent is a major issue in the GDPR and ambiguous tick-boxes are not acceptable. Privacy notices must be crystal clear and written in Plain English. Clients must have the option to opt-in or opt-out if you collect data from them.

The Right to Data Erasure

All individuals have the right to request that their data is permanently deleted. So, if Carlos from Barcelona decides to jump ship to another DevOps startup, he can legitimately request that you delete his HR file. He can also ask you to send his file to his new employers.

Data Protection Officer

Companies that process large amounts of data or are involved in the monitoring of individuals—this is applicable if you track online behavioural patterns for marketing purposes—must appoint a data protection officer. This person can be anyone, but they must have knowledge of data protection practices and the law related to data protection.

Not everything has to cost in meeting GDPR data compliance, though; there are many free resources your startup can use as well.

Speed

One concern is the impact on speed that GDPR will bring. Eighty-one percent of IT operations professionals believe information security policies slow them down. Avoid this for your startup by doing the DevOps yourself as it will make software deployment faster. However, insecure system changes could then be shipped through. Automation can offer a solution.

Automation

Treating compliance through continuous automation means your DevOps startup will put code-based controls through the normal development process: test, version, apply and modify. This makes such controls easy to collaborate on and running compliance scans will become a common feature in the development stage, testing environments and production systems.

The average idle time before identifying a system breach is believed to be 200 days. Continuous automation means that such an issue could be detected on the engineering team’s development workstation, before it reaches production and ensuring it is dealt with to make things safe and guarantee GDPR compliance.

What Not to Do

The thing you absolutely shouldn’t do is ignore GDPR on the basis that it doesn’t apply to you, “because who’s going to know if Carlos from Barcelona works for my startup and so what if one of my computers is struck with ransomware and everyone’s bank details are leaked onto the Dark Web?”

The GDPR will affect millions of businesses, so all startups need to be aware of how it will affect their operations. If you don’t comply with the directive, it could prove to be a costly mistake. Ignorance is never a legitimate defense in the eyes of the law, so check out the EU GDPR website and get informed. If GDPR doesn’t affect you, great; but if it does, think like a Boy Scout and Be Prepared.

— Murray LeClair

March 16, 2018
Salesforce Moves Compliance to the DevOps Left

Compliance is one of those tasks that trips up developers multiple times over. More times than anyone cares to admit developers finish an application only to discover there are any number of compliance controls that were overlooked. Sometimes, bringing that application into compliance is trivial. Other times, it can delay the rollout of the application by months.

To help mitigate this issue, Salesforce this week added a Heroku Shield module to Heroku Enterprise, its container-based platform-as-a-service (PaaS) environment available to IT organizations needing access to a dedicated platform running on Amazon Web Services (AWS). Dylan Steele, vice president of marketing for the Salesforce platform, says Heroku Shield enables developers to comply with a broad range of mandates ranging from payment card standards to any number of healthcare regulations. The goal is to automate meeting regulation compliance by making it possible for developers to automatically add the appropriate controls to their applications.

Heroku Shield requires mandatory encryption for data at rest in addition enforcing a stricter level of TLS encryption for applications deployed in a Shield Private Space. It also enforces trusted IP ranges and manages application-level authentication tokens.

The move is part of the effort to shift left more of the responsibility for IT security, by making it easier for developers to address security and compliance issues early in the application development process. That’s when the cost of fixing those issues is substantially less than when that application is deployed in a production environment.

In general, there’s not a lot of love lost between developers and auditors. Developers often feel that the controls needed to achieve compliance are not all that clear. Auditors feel that many developers are simply too lazy to implement the appropriate controls in the first place. In truth, however, there’s a lot of commonality between the control required to meet various compliance requirements. That creates a lot of opportunity for PaaS environments that abstract the underlying infrastructure away from developers to automate implementing a broad range of compliance and security controls. The biggest issue now may be simply making developers aware that’s possible.

In the meantime, DevOps teams that regularly struggle with compliance issues at the back end of an application release cycle might want to reconsider their approach. Whether it involves a PaaS environment or not, there’s a strong case to be made for moving testing of compliance controls as far left as possible in the application development process. Not only does that approach minimize the number of compliance issues that may arise before and after an application is deployed, but the documentation generated during the development process should substantially reduce the amount of time auditors spend crawling over and around an IT environment. That’s critical, since most auditors charge by the hour, and every minute they spend on an audit also increases the probability of finding something else that needs to be fixed.

— Mike Vizard

June 8, 2017
GRC: A Key Ingredient in DevOps’ Secret Sauce

By now, surely everyone has seen cooking competition shows such as “Hell’s Kitchen” and “Top Chef,” in which people compete to create and serve the best dishes as quickly as possible. These hit TV programs are like the DevOps world, which also consists of people creating and releasing the best software as fast as they can with whatever they are given. In both instances, the best use of random ingredients brings rewards and failure brings disappointment.

DevOps is becoming evermore common as companies in all industries work to unify their developers and other IT staff while automating as much of the process as possible, creating nimble, fast-moving teams. Think of it in the same way professional kitchens have cooks dedicated to specific stations, such as vegetables or fish, and are able to react swiftly to whatever orders are placed. By redesigning their in-house teams in this fashion, organizations can add speed, agility and resilience to critical functions.

But, often what’s forgotten in the high-pressure, rush-rush-rush world is the critical importance of security and regulations. Governance, risk management and compliance (GRC) always must form the base decisions; otherwise; the final products will either not be able to be used or, worse, be dangerous to the company, its customers and its shareholders. It’s really no different than cooks having to abide by health code regulations or risk sickening and possibly even killing their diners. Don’t think GRC is that serious? It wasn’t long ago that Dwolla was fined $100,000 by the Consumer Fraud Protection Bureau (CFPB) for lying to customers about data risks. That was the CFPB’s first fine and you can bet more are sure to follow.

Of course, a key difference is that in the business world, regulations and compliance standards constantly are being created or changed. That makes DevOps even more challenging, but that challenge cannot mean ignoring GRC. In fact, GRC should be seen as a key DevOps enabler, not an obstacle. An organization’s legal and compliance team can take advantage of highly agile, forward-moving DevOps teams to design and implement changes that satisfy risk and control points (resulting in successful audits and avoiding fines) while, at the same time, staying abreast or even beating the competition.

The key here is to ground DevOps in GRC requirements so they become second nature and security measures are incorporated effectively into all DevOps processes, even automated ones. It’s crucial these measures are seen as integral to the processes and not simply layered on top as an afterthought, just as you wouldn’t try to get raw chicken juice off of lettuce after you’ve made a salad.

Tactically speaking, how is this accomplished? DevOps teams need awareness and training. They need to learn the rules and laws specifically governing their particular industry, and how to implement them. And, companies need to have internal audits and other review policies in place to ensure GRC is enforced.

For all of this to happen, however, a very important role must orchestrate it: management. Just as every kitchen depends upon a head chef to ensure not only that each station is obeying health codes (i.e. the law) but also that overall the meal is being prepared and delivered properly, company management must assume its authoritative role in setting up and defining the organization’s internal communication. This means breaking down silos and coordinating a regular flow of information from Compliance to DevOps team and back again.

If this is done properly, DevOps can enable an innovational Nirvana, with companies boosting speed while maintaining security, creating the perfect consumer experience.

About the Author / Robert Hawk

Robert Hawk serves as Information Security Expert at xMatters, Inc. He has extensive experience in information systems security, computer security, cyber security, information assurance and governance, risk, and compliance (GRC) management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

September 8, 2016