In the CISO Desk Reference Guide, I noted how critical the concept of “context” is to security programs. The same holds true for our organizations and their respective privacy programs. The foundation for any privacy program is understanding – and critically documenting – the nature and extent of the personal data (PD), personal identifiable information (PII), protected health information (PHI) and other forms of sensitive personal information (SPI) that the organization collects, processes, shares and retains. This is where context is integral to underpinning the critical work associated with data discovery and data classification. Before delving into discovery efforts, it’s important to tackle the challenges with data classification and data retention.

Similar to data retention, data classification tends to be an organizational hot potato with ambiguous understandings as to who should classify data and, by extension, who determines the data retention period based on the data’s classification.

Declare war on ambiguity
Data classification and data retention practices are made overly complicated and impede both security and privacy programs. In my view, data classification should first and foremost be governed by regulatory and/or contractual contexts. If HIPAA defines PHI, should organizations create their own definition of protected health information? No! If the GDPR defines personal data – as it does in Article 4 – should the organization create a unique definition? Again, no! Let regulations do the heavy lifting of data classification. Of course, there’s nuance here. Definitions of “confidential,” “proprietary” and “sensitive” information should be contextualized to the organization and defined by counsel, the executive leadership team and other identified key stakeholders. Retention periods should follow a similar methodology. If a regulation calls for a specific data retention period, implement it and validate it. Other data sets that are not subject to regulatory and/or contractual obligations should also reflect organizational context and organizational priorities, recognizing that one of the core principles in privacy is data collection and data retention minimization.

Unless there’s a valid regulatory or contractual requirement to collect and retain data, the collection of personal data and its retention should be limited and tied to its stated purpose. Far too many organizations have an unfunded liability on their hands as they retain personal data that is no longer tied to its stated purpose and, if/when there’s a data breach, the individuals behind these records would be entitled to credit monitoring and other recourses, including a personal right of action here in California (based on the California Consumer Privacy Act (CCPA), which will become the California Privacy Rights Act (CPRA) in 2023). Data minimization also frees up storage and administration costs associated with records that are no longer tied to a particular purpose or governed by a mandatory retention period.

Organizational context a must
Our privacy and security programs need organizational context to function correctly and align practices of both programs with agreed-to risk tolerances and organizational strategy. Too frequently, however, both programs function in a vacuum. This has to change. There are some simple, but detailed steps to overcome this disconnect. Fundamentally, we can enrich our respective understandings of organizational context with three tools: business impact analyses (BIAs), data flow diagrams (DFDs) for material systems (defined as those business processes, systems, and/or applications that collect, process, or store data elements that include PD, PII, SPI, PHI, etc.,), and privacy impact assessments (PIAs). Successful security and privacy programs are well-served to devote resources and attention to each of these tools. Let’s highlight why BIAs, DFDs, and PIAs are so powerful. 

Business impact analyses are foundational to governance and provide a treasure trove of detail for organizational stakeholders. BIAs should first and foremost capture how the organization derives enterprise value. Effectively, what are the business processes that are most material to the organization? As these are identified, a basic dependency analysis should be performed. Specifically, does the material business process have dependencies upon technology, specific data sets, staffing levels and competencies, vendors, suppliers, locations, or other variables, and how are these dependencies managed? BIAs are foundational to business continuity and disaster recovery planning as they ideally distill recovery point and recovery time objectives for those processes that are integral to the organization and its operations. BIAs also capture department priorities, department context, and broader organizational priorities when responding to security, environmental and other operational incidents that have a business impact. BIAs, similar to PIAs, should be considered living documents that are updated and revised based on changes to the organization’s environment. Overtime, BIAs can become more useful as they add additional context and detail to identified material processes within the organization. While not necessarily at the same level as a process narrative in the context of Sarbanes-Oxley or a record of processing activities as would be required by Article 30 of the GDPR, BIAs should seek to provide a baseline description of the identified business process. Essentially, the BIA can provide an important snapshot of the organization, its business processes, and the general risk and dependency context associated with the same.

Data flow diagrams (DFDs) can be used to highlight how information enters the organization and internally which departments, systems, applications and IT infrastructure process and store that data. DFDs are excellent tools to highlight how data moves into and out of the organization and, from a security perspective, where there are trust boundaries. To be clear, however, data flow diagrams don’t need BIAs as a condition precedent to begin. When I was a research direction and security analyst at Gartner, I spoke to down-and-dirty approaches to building DFDs. As I would tell clients, “Grab a blank piece of paper, draw two vertical lines such that you have three columns.” The left column represents the sources of personal data that enters the organization – be it from consumers or employees – the center column outlines how this information is used internally (processes, applications, systems, and IT infrastructure, data sinks (storage), etc.), and the right column represents those external entities with whom the organization shares personal data information (e.g., data processors). The two lines again represent trust boundaries from a security perspective and critical demarcation points from a data and privacy governance perspective. The BIA and DFDs can be complemented by analyzing data flows in the context of the data privacy lifecycle (e.g., from notice, consent, collection, use, sharing, retention, through destruction). Prior to personal data being ingested, privacy stakeholders should verify if the notice that has been provided is consistent with the contemplated processing activities. The DFD can help identify where consent may be required and noted as either explicit or implicit in nature. The beauty of DFDs is that they are approachable to varied audiences, such as technical teams, executive management, and of course, privacy and security leaders. DFDs do not need to be complicated … again, just start with a blank piece of paper, draw two vertical lines, and start filling in the details.

Privacy impact assessments are the third tool that should be used to help derive additional context related to privacy practices as well as data discovery and classification initiatives for the organization. Basic “observation and inquiry” is a great complement to more technical approaches to data discovery. Privacy leaders need to know the enterprise and meet with department leaders, notably in sales, marketing, HR, and IT to get a better understanding of the nature and extent of personal data collected and used by the organization. PIAs, similar to BIAs, are there to add detail and important context to personal data processing activities. The aforementioned Article 30 of the GDPR offers excellent insights as to what should be captured in these assessments. Most critical is the evaluation of the stated purpose for personal data collection as conveyed in the privacy notice (policy) and whether these contemplated practices are reflective of actual practices. Where there is a disconnect, the privacy leader should raise this risk to other members of the executive leadership team. Section 5 of the Fair Trade Commission Act (overseen by the FTC) explicitly prohibits “unfair and deceptive trade practices.” The FTC assertively enforces actions against organizations that state one thing and do another. PIAs, like BIAs, should be considered living documents that facilitate ongoing awareness of privacy practices throughout the organization and through the privacy lifecycle. Effectively, the privacy leader should continually ask ‘What is it that I don’t know about my organization’s privacy practices that I should know, and how do I determine that status?” BIAs, DFDs, and PIAs are there to help answer that basic question.

The insights derived from these three tools underpin governance and risk management practices for the organization. Moreover, the core body of knowledge that is incorporated into ISACA’s CDPSE, CRISC, CISA, CGEIT and CISM certifications help privacy and security leaders understand the critical linkages between governance and technology, and appropriate risk management for their respective organizations.

Originally published on ISACA BLOG NOW on Feb 2, 2022

Recently I had the opportunity to sync up with two of my colleagues at EVOTEK, Paul Ferraro and Amir Fouladgar. Paul curates an outstanding technology podcast and we had the opportunity to discuss the state of security and some observations as we head into the new year. I wanted to outline what I think are important priorities that will shape not only our security programs, but most importantly, the overall resiliency of our organizations.

1.     We should be passionate about automation and orchestration. Our profession is filled with highly talented individuals doing critical work manually. This must change. As security leaders, we need to empower our teams and given them the tools they need to respond to adversaries that move at network speed. Our adversaries are competent, well-resourced, and frequently more automated in their techniques then we are at defending our own organizations. Let’s make 2020 the year where automation of mundane tasks and the orchestration of more responses becomes the norm, not the exception. I am bullish that SOAR will be part of the modern security architecture. For this to occur, however, we need vendors to focus on interoperability and more reliable API-integration between and among security applications.

2.     Alert fatigue is real. Security analysts are inundated with tickets and alerts that are too frequently false positives. This status quo puts our organizations at significant risk. Analysts who face never ending alert queues and the manual investigation that follows, will miss things. They will also leave our organizations for greener pastures…companies with more modern security architectures. Let’s empower our teams. I’m a huge fan of using deception to focus on real threats that have bypassed existing security controls and traditional security monitoring. Deception is a game changer. The adversary now must worry whether they are interacting with decoy assets (be they credentials, servers, or otherwise). The use of deception technologies offers high-fidelity alerts and greater insights into adversarial TTPs. Deception allows us to effectively push the adversary back on their toes.

3.     Data governance and privacy are driving greater alignment between security practices and the business and its operations. CISOs should consider their colleagues in privacy as natural advocates for good security practices. As the saying goes, ‘you can have security without privacy, but you cannot have privacy without security.’ To reduce data breaches, we need to understand data flows from a business perspective. Privacy Impact Assessments (PIAs) are useful not only to our colleagues in privacy but to our security efforts. They can help outline where trust boundaries should occur, where data validation should be enacted, and where and how data and sensitive information enters the organization and where it’s shared with third parties. With the California Consumer Privacy Act (CCPA) coming into effect, there’s never been a better time to take a data centric or information centric view of security. I’ll be overseeing a track on data governance and security leadership at EVOTEK’s upcoming security conference where we’ll be addressing best practices for data protection and data governance.

4.     Let’s give back to our profession and help new entrants succeed. When I was an analyst at Gartner, I had the opportunity to collaborate on some important research that my former colleague and still friend Sam Olyaei was doing on the cyber skills shortage. This problem is larger than any organization. Collectively we can help mitigate the skills gap by helping new entrants to the cybersecurity profession gain requisite skills and find mentors who can help them with their careers. As a case in point, our local San Diego ISACA chapter sponsors student memberships into the organization. Let’s find ways to be there for those just beginning their careers in cybersecurity.

5.     The value of collaboration and sharing cannot be overstated. I remain grateful to the San Diego CISO Round Table for engendering a collaborative security community. This collaborative spirit was foundational to Gary Hayslip, Bill Bonney and I working on the CISO Desk Reference Guide. Our books on the role of the CISO would not have been possible had it not been for this collaborative environment. Kudos to Macy Dennis and the other board members for maintaining this community. There are outstanding organizations including other regional CISO Round Tables, ISACA, OWASP, InfraGard, and ISSA that offer fantastic opportunities to share best practices and find creative ways to deal with the many challenges that cross our desks every day. Collectively and collaboratively, we’re stronger.

6.     Let’s not overlook some of the outstanding work that’s being done in security today. Our security architectures are getting better – sadly, so too are the adversary’s techniques. The work being done by MITRE with the ATT@CK Framework is truly second to none. When the ATT@CK Framework is coupled with threat modeling and the use of deception, our adversary’s will face real obstacles and our organizations will become more resilient. Kudos as well to NIST. I love seeing the continued progress and adoption of NIST’s Cybersecurity Framework (NIST CSF).

7.     We will likely see greater consensus on ‘reasonable’ security coming into 2020. The CCPA will drive this discussion forward. I’m fortunate that I’ll have an opportunity to speak on this topic at the upcoming Wall Street Journal Cybersecurity Symposium (https://cybersecurity.wsj.com/symposium/san-diego/) with an outstanding advocate for privacy and reasonable security practices, Justine Phillips, from Sheppard Mullin. As a quick aside, kudos to Justine and the extended team at the University of San Diego for hosting the second annual, and outstanding, Cyber Law, Risk and Policy Symposium earlier this year. The Symposium has become a must-attend conference on the important intersections that now bridge the legal, privacy and security professions.

Given that the topic of ‘reasonable’ security is top of mind for security and business leaders alike, I’d like to offer the following definition to start the dialogue (this is certainly not a legal definition):

“Reasonable security is that level of security capability that meets the organization’s agreed-to risk tolerances while fulfilling regulatory requirements and contractual obligations of the organization.”

I’d like to wish everyone the best coming into 2020. Here’s to a more resilient future.

Happy New Year!

Matt

With Black Hat and DEF CON coming up and this year’s RSA Conference and Gartner’s Security & Risk Management Summit completed, I wanted to reflect on an odd dynamic we face in security, one made all the more poignant for CISOs who have walked the exhibit halls of these conferences. We have an abundance of choice in our profession. Security, however, is ultimately about prioritization.

• Which assets warrant protection?
• How should these assets be protected?
• What is the best technology to protect these assets?

The image below highlights how crowded the security application and tool space has become. Estimates vary, but it’s safe to assume that there’s over 1,000 vendors in the security marketplace today with each vying for a finite security budget. Many security categories have more than 10 vendors battling for market share with their respective products. There’s not only competition within categories but increasingly among categories as one technology purports to address a security control traditionally handled by another. Selecting the most effective technologies when confronted with seemingly limitless choice is not easy.

When I was a research director with Gartner’s security and risk management practice, I had the opportunity to speak with a well over 1,000 fellow CISOs as well as CIOs and other risk-management leaders. While most of my discussions focused on my research coverage – incident response, security compliance, privacy, IT risk management, security program design & evaluation and the cybersecurity skills shortage – many discussions delved into the efficacy of specific security applications and tools. My response was consistently that our security architectures have become inordinately complicated Venn diagrams with significant overlap in feature and functionality among the applications used in our security programs.

The amount of choice we have comes at a significant price. All of us in the industry recognize that attracting and retaining technically-competent staff is challenging. Finding security engineers with have hands-on experience with so many different tools and applications is both costly and difficult. Further, there is the issue of defining which application or tool should function as the system of record for a given security control and how other tools and applications should integrate into the defined system of record through APIs and other integration mechanisms.

Beyond the operational complexity of managing so many different applications, there are financial and procurement concerns with so much choice. Too many options and approaches to address security controls generates widespread confusion during the procurement process, especially with non-technical buyers who fund projects. There is also buyer’s remorse when a specific security requirement could have been addressed with an existing application or tool had that feature been enabled or the capability configured and implemented correctly. This buyer’s remorse worsens when newly implemented security applications prove ineffectual and frankly don’t address security risk adequately. There is also the dynamic of “required” security applications – those appearing on an auditor’s checklist – versus newer technologies that solve problems in innovative ways that an untrained auditor may not understand.

Here’s the question that I’d like to posit to the CISO and broader security community. If you could only incorporate 5 security technologies into your environment, what would they be and why? Effectively, which 5 security technologies would produce the best return on security investment and reduce risk by the greatest amount?

I don’t want to unduly frame your response but I will offer some initial broad categories for consideration. Please note, this is not a question about vendor A is better than vendor B. I’d like to explore which technologies are viewed as the most effective and the rationale for their selection. This rationale may include considerations such as ease of implementation, security effectiveness, cost effectiveness, etc. As the image above notes, there are ample categories to consider including deception, network access control (NAC), firewalls, endpoint protection (EPP), endpoint detection and response (EDR), security incident and event management (SIEM), security orchestration automation and response (SOAR), intrusion detection/prevention systems (IDS/IPS), breach and attack simulation (BAS), threat and vulnerability management (TVM), identity and access management (IAM), secrets management, privilege account management (PAM), network traffic analysis (NTA), static application security testing (SAST), dynamic application security testing (DAST), security awareness training, secure email gateways, cloud access security brokers (CASB), secure web gateway, credentials management, web application firewalls (WAF), encryption, among others. Many of the technologies now have their “next generation” variants (e.g., next generation AV, next generation firewall). There are undoubtedly many other technologies. The categories above are to simply start the dialogue.

If you were building your security architecture from scratch, which 5 security technologies would be part of your reference architecture? Which risks are the most critical and how do these technologies reduce that risk accordingly? As I noted at the beginning of this article, security is about prioritization. Given the constraints on our budgets and staffing competencies (which we all experience), which security technologies should be prioritized first and why? Clearly, your industry and your business model will influence this analysis and should be part of how your look at this question.

I look forward to an open and collaborative dialogue.

When NotPetya, Petya, Ryuk, SamSam, WannaCry, CryptoLocker, TeslaCrypt, among many other variants of ransomware, are so frequently addressed in popular media and covered on shows like 60 Minutes, you know we’ve got problems. Ransomware is not only in the spotlight of popular media, it also has the attention of executive stakeholders in organizations. This presents an interesting opportunity for CISOs.

Recently publicized cases such as those for the cities of Atlanta, Baltimore, and Albany – let alone a number of others incidents across municipalities in Florida – along with the frequently cited and historic examples of Hollywood Presbyterian and Maersk – suggest that ransomware is a symptom of a larger issue. Too much of our infrastructure is vulnerable to ransomware and other cyber attacks. The “standard” of “reasonable security” is clearly not being met.

Without getting into the technical details of how ransomware works, it’s important to note that these attacks exploit vulnerable IT infrastructure and many of the protocols used in common applications and operating systems. In many ways, the current challenges with ransomware are reflective – analogous – of broader concerns with infrastructure across the country. When systems are not maintained correctly, they become vulnerable and prone to failure. We see this in our nation’s critical infrastructure including notable examples such as the bridge collapse in 2007 in downtown Minneapolis that took the lives of 13 people and injured over 100. My prayers are with those families.

More than ten years after this tragic incident, much of our country’s critical infrastructure remains brittle and will continue to fail resulting in injury and the potential loss of life. The risks created by ransomware can have similar impacts. As more operational technology (OT) gets connected to traditional information technology (IT) networks, system failures will impact the physical world. This is happening now with connected devices and the growth of IoT. My fear is that the consequences of security failures will result in the loss of life. This is a game changer.

Imagine a ransomware attack that locks the controls of autonomous vehicles or blocks access to medical devices. The scenarios are many and the consequences are real. Media coverage to date has focused on financial costs including ransom payments and/or the direct and indirect costs of remediation following an incident. Think of the media coverage when there’s attribution that a poorly configured device or application resulted in physical harm or death. Our world will change and quickly. The disclaimers of warranty and limitations of liability that are associated with so many of the products we use will likely not survive resultant class action lawsuits. The consequences of IT infrastructure administration and application and product design have never been higher, but similar to our nation’s physical infrastructure, there is significant technical debt (effectively an unfunded liability) that needs immediate attention.

Clearly, ransomware is a real and present danger to organizations of all sizes and in all sectors of our economy. So too are the numerous other security risks faced by our organizations. Many of us who serve as CISOs recognize that there will never be perfect security and we have to assume that our organizations will continuously confront security incidents. Our objectives are to quickly detect and mitigate these risks and to make our organizations more resilient (the ability to withstand security and other incidents and keep risks within agreed-to parameters). In this context, the topic of ransomware offers us a great opportunity to take pause and evaluate just how prepared our organizations are to confront these exposures. Incident response planning has never been more important. 

I would like to change how we think about ransomware. This current media attention on recent cases offers us an opportunity to evaluate the resiliency of our IT infrastructure and the efficacy of our security programs. We all recognize that we need to maintain our systems, harden our configurations, and patch more timely (effectively security hygiene). This is what we’re paid to do. Too frequently, however, our requests for resources to help secure our infrastructure and make it more resilient are not adequately contextualized to organizational priorities. Bluntly, non-IT and non-security stakeholders don’t fully understand the enterprise risks of not doing the basics well and not funding the resources required to make the organization more secure and resilient. The result, technical debt accumulates. Similar to our nation’s infrastructure, much of the enterprise IT infrastructure we are expected to manage and secure is fragile…subject to exploits and breaches. Too frequently, executives don’t understand these risks and cannot adequately link cyber risk to impacts on organizational strategy and goals. As CISOs, we’ve failed these stakeholder in not conveying security risks in terms they can understand.

When security incidents affect the bottom line, expose the organization to legal and regulatory demands, negatively impact operations and damage an organization’s reputation, executive management and the board will take notice. Frequently, given media attention, CISOs are asked “Are we secure?” This questioning would be better served if it were “How resilient are we?” That’s a question a CISO would love to explore with executive management and the board. The current attention created by highly publicized ransomware incidents should serve as the impetus for stakeholder discussions on organizational resiliency. CISOs and CIOs need to ensure that these discussions are not laden with technical jargon and “the sky is falling” scenarios. We need to explain the benefits of resiliency and preparedness in terms that other members of the C-Suite can relate to and importantly contextualize and directly link to their organizational priorities.

The good news is that our ability to make our organizations more secure and resilient has never been better. We’re seeing advancements in security orchestration automation and response (SOAR) technologies as well as innovative approaches to security visualization and analytics that surface security issues and poorly configured environments in a more intuitive and near real-time manner. That’s empowering. Similarly, improvements in enterprise backup and storage systems mitigate risks to data. Our security toolbox has also improved and covers the proverbial full-stack of infrastructure ranging from code development to in-production applications. Cases in point include a number of preventative capabilities ranging from enhanced endpoint protection, network detection and response (NDR), endpoint detection and response (EDR), web application security, network segmentation, identity and credential management capabilities, network access control (NAC), deception technologies, and even security awareness training – including many popular tools that phish end users to raise awareness. CISOs have never had such a suite of capabilities before. Obviously, these capabilities require access to trained personnel and the budget to leverage these tools.

CISOs today have reason to be cautiously optimistic…we have board and executive attention on our security programs and access to tools and capabilities that are more effective than ever. We still have to deal with the skills shortage our profession faces but our knowledge of adversarial behavior has improved notably thanks to MITRE’s ATT&CK framework and insights on the tactics, techniques, and procedures (TTPs) of those trying to harm our organizations. CISOs should exploit – pun intended – media attention on ransomware to have more open and direct conversations with their colleagues in the C-suite and the board and use this opportunity to drive a business-aligned resiliency agenda. If the topic of resiliency is not on your next meeting agenda with fellow executives, it’s time to add it now. Make resiliency a standing agenda item and ensure that incident response preparedness includes not only the IT and security teams, but stakeholders throughout the organization.