DevOps Is Failing These Three Tenets of Privacy Compliance
DevOps Is Failing These Three Tenets of Privacy Compliance
Automated tests and monitoring might not be enough to catch your security flaws. Read about privacy compliance and why DevOps might not be doing enough.
Join the DZone community and get the full member experience.Join For Free
This is part 2 of a blog series exploring common mistakes and best practices in testing. This week’s blog is about privacy compliance.
Think your automated tests will catch your security or privacy vulnerabilities? I’ll bet you’re wrong.
I know, data is streaming from multiple sources into your SEIM systems, and you’ve configured triggers for your reporting. You’re watching results from automated tests on software running in production. All your monitoring tools say your code is running flawlessly and there are no errors. You’re running automated tests, just as the DevOps playbook suggests, but they won’t catch security or privacy compliance vulnerabilities. Why not? DevOps is falling behind.
The Hard Truth About DevOps
Three Tenets to Privacy Compliance
It’s a lot to contend with. To address privacy by security appropriately, you have to embed privacy by design from the beginning. It can’t be bolted on.
In fact, properly patched code is 80% of security. The firewalls, antivirus software, and other additional elements are backup measures in case the fundamentals don’t work. Think of proper code as the moat and the drawbridge, while the guards are the firewall. If a product or service is at the highest quality possible, privacy and security will be embedded and seamless.
Organizations have gravitated toward DevOps because of its emphasis on process, collaboration, and automation. Unfortunately, automation has come at the expense of other things like privacy and security.
Are Privacy and Security Real?
Your privacy and security are as meaningful as their alignment between your security implementation and your need for privacy and security. If those things are not aligned, privacy and security are just academic concepts.
When we run tests, we’re testing the code to see whether it works. Security may not be in the testing scope. For many companies, security is tough to test for because it’s in the firewall and antivirus software. Let’s look at another industry:
When Ford introduced the Model T in 1908, he revolutionized production with the assembly line. The Model T gave people what they wanted: fast, reliable transportation at an affordable price.
The Ford Model T revolutionized production.
Security features? None. Later, of course, Ford introduced an electric starter, a foot accelerator, a foot brake, dashboard gauges, seat belts, air bags, crumple zones, firewall, and more. Security and safety are built in. Having those features built in from the start helps to ensure quality, and in the modern era these points are regulated by law makers.
Today’s cars have hundreds of sophisticated safety features. Rear-view cameras, fluid level sensors, tire pressure sensors, nearby car detectors, auto correction technology for staying in your lane, and more features are built in from the start.
Back to our story: The same thing is happening to information technologies and information systems. Security is an artifact of the youth of the industry. Innovations come out of immature industries, and security is fully integrated when the industries become mature.
Security requires three things: safety from things that don’t work right, safety from malicious activity, and privacy protection. Security regarding things not working and defense against malicious activity have advanced since the software industry has started to mature. Privacy compliance is still growing and evolving.
Privacy compliance is an evolutionary arms race. Social and business factors increase risks. Laws change to enforce behaviors that will mitigate those risks. And the security features built into your code comply with the laws and offset the behavior of both well-meaning and nefarious people who interact with your company’s code and infrastructure.
Testing and Monitoring Recommendations
Monitoring: Employ different techniques to detect and prevent issues.
Testing: Testing your service in conjunction with the monitors you have in place.
Automation: Automate repeatable processes.
Delivery: Account for environment variables for notification delivery.
Service Health: Exercise your services in different ways to gain a holistic view.
Transparency: Be transparent and honest with your customers.
Next Steps in Security and Compliance
There are three things you must do to ensure security and compliance given the current state of business.
First, validate code as part of development. There are a few ways to do this. You can have it validated by other human beings, but of course, human beings make mistakes. You can also use automated scanners against known vulnerabilities. A third option is a function map or workflow vetted by someone who knows privacy. That person could be a lawyer with technology cross discipline, or it could be a privacy expert on staff.
Second, make sure you’re not breaking any laws when you’re coding and writing processes for automation. There is no magic way of knowing whether you are in legal compliance. In adherence with DevOps best practices, you must map function and workflows from a legal perspective.
Third, document the function and workflow. Function and workflow should not live in people’s heads! When documented and shared, workflow helps to support the collaboration that is the heart of DevOps. When you integrate privacy and security into your product by design, you put your organization on the road to providing effective, safe, and secure software to your customers.
We Are Always Improving
At xMatters, we strive toward integrating privacy compliance into our products and services. We do this by constantly improving our understanding of privacy compliance requirements and applying a risk-based approach to introducing security controls.
Security controls span physical, technical, and administrative domains. Using a tiered approach, we use technical controls first. Where technical controls are not available or have failed, we use administrative controls such as awareness and training. Administrative controls are focused on individuals in regard to necessary information. In other words, we use context and situational awareness to get the right information into the right hands. We build processes to avoid overwhelming people with unnecessary information or keeping people from the information they need to do their jobs.
There is a misconception that privacy and security require technical solutions. And to an extent, that’s true. But really, it’s a people issue and needs to be solved through training, awareness, and the flow of information.
We use these fundamentals not only to protect ourselves, but to protect our valued customers. By understanding the unique requirements of each business, we can help our clients understand how their data is being used and help them stay compliant with the law- and safe from untrustworthy hands.
We are in a time of great change, and some situations have no precedence to guide us. Changes to Safe Harbor are a good example. And now, regulators are building teeth into laws by applying enormous penalties for running afoul. We are confident that our proactive stance on compliance and safety will continue to serve our customers well.
Published at DZone with permission of Robert Hawk , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.