When developers hear the term "shift left," they often think about the traditional waterfall delivery model, and how security must shift earlier in the application lifecycle to reduce cost and friction, and increase quality. But that definition focuses too much on waterfall and not enough on your DevOps culture.
That said, the intention here is absolutely spot on. Waiting for your organization and products to mature beyond your level of control, and having to manage breaches in trust and privacy scandals, can result in CEO-level manifestos (this Facebook memo is a prime example), CEOs explaining how technology works to Congress (Google), or CEOs explaining how good their security program is even though they allowed a massive compromise of personal information (Equifax).
There's been an increase in accountability with regard to individual privacy rights, and because large organizations have violated that trust, we should expect a greater need to incorporate security throughout software delivery lifecycles. What better place to start, then, than existing touchpoints within your security team?
There's already a greater emphasis on consumer-level privacy expectations with the California Consumer Privacy Act (CCPA), which will lead to privacy teams looking for partners across the organization to ensure compliance.
If the General Data Protection Regulation (GDPR) was not a comprehensive effort organizationally—perhaps your non-European Union business dodged the proverbial bullet with compliance requirements, or simply opted out—there are some things you should be thinking about to get on track. As an information security professional with the opportunity to build application security programs, you already have a competitive advantage to get things moving rapidly.
Here's how get on top of privacy engineering in the DevOps age.
Application risk profiles
Most application security and information security programs develop an inventory. If you don't have an inventory of web applications, mobile applications, and APIs, then you don't have the context to know how to test your organization at scale.
For inventory such as an Internet-facing mobile banking app that processes customer personally identifiable information (PII) and moves money or an internal employee-only interface that your call center employees can use to access any customer's information, it's a best practice to classify and notate what and where your data flows are.
This also adds to the understanding of privacy and regulatory implications across your inventory. Most organizations start with simple manual processes or questionnaires, and that's a great starting point to determine what data elements are required as you shift the privacy discussion earlier.
With role-based access controls, you can limit employee access to sensitive customer PII, requiring a secondary authorization to reveal a tokenized or encrypted value for a customer record instead of displaying it for generic operations. The challenge of questionnaires is that sometimes they can be difficult to scale, especially if your organization is early in its security journey.
Testing for privacy
A secure software development lifecycle (SDLC) offers multiple touchpoints that can help the accuracy of the inventory. Ethical hackers can also help, revealing vulnerabilities about applications, dealing with situations where error handling reveals too much information or databases are exposed, or enumerating how a poor login password recovery flow can identify customer information from an underprotected API.
Here's another tack you can take: Within many frameworks of penetration testing—OSTTMM, PTEST, etc.—there are steps you can take to reveal sensitive details from applications. Feed those identified vulnerabilities back into the lifecycle to prove that your inventory and questionnaire process is effective. Or have a conversation with the product manager to establish a true understanding of the data flows.
Automate the analysis
Use questionnaires and risk profiling to get details about your application on a change- or time-based cadence as it is being designed or evaluated. The rubber hits the road when you automate the analysis of data and patterns.
Preferably this capability will come in the form of a tool that uses artificial intelligence or machine learning. This tool should have an inherent ability to evaluate the actual data sources (columns in a table) or data in motion (payloads) to perform accurate risk profiling.
These opportunities are not limited to mature programs, but are usually reserved for those that can instrument directly or afford technology and services to supplement their process in order to identify real data in motion.
A modern solution for modern companies
You'll probably be playing catch-up when analyzing real-time data, but it allows you to have additional controls for real-time blocking and protection—and you can then align application security programs with privacy and compliance teams.
As more organizations move to the cloud, they must look to modern programs. Even if you can't instrument a mechanism to shift left or have privacy by design, you can implement systems that will reduce the likelihood of a breach or privacy incident.
Keep learning
Understand the newest privacy laws with this Webcast: California’s own GDPR? It’s not alone.
Take a deep dive into the new privacy laws with TechBeacon's Guide to GDPR and CCPA.
- Get up to speed on cloud security and privacy and selecting the right encryption and key management with TechBeacon's Guide.
