Your organization’s security stance must be supported by everyone in the company, every day, in all that they do. However, people are focused on their jobs, not necessarily on security. With attacks increasingly starting at the human level through social media or targeted emails, your organization needs to create and maintain a high level of security awareness among the workforce so that everyone is an active participant in helping to secure company assets. Here are some ways to bring a security awareness mindset to all employees.

Partner with HR to deliver training

While “security awareness” is of interest to CISOs and CSOs, the training aspect of raising awareness really should be a function of HR or whoever does corporate training for your organization. A best practice would be to integrate the content of what you want employees to know into regular employee training—especially for new hires. This way, security awareness and training is a routine part of staff development for everyone.

A CISO from a healthcare organization explains that he is given two full hours on the agenda of his company’s two-day new hire orientation training. Because the requirements of HIPAA compliance are so important in a patient care environment, his team spends one hour discussing the privacy requirements for electronic protected health information (ePHI), and a second hour discussing how to safeguard that information. Security and privacy training are not standalone topics; they are tightly integrated into what every new employee must learn and embrace.

By having HR handle training aspects, you can distinguish your security program as the messenger when exceptional communications are required. For example, when your company is suddenly being hit by a phishing attack and you need to raise an alarm about it, your security program can send out a message to everyone saying, “don’t click on that link.” Because the message is exceptional, it doesn’t get lost in all other communications and people take notice.

Training programs can include formal classroom instruction, customized online courses, and even online awareness programs that test and teach people through simulated attacks (ala Wombat, PhishMe, etc.). People learn in different ways, so it’s helpful to provide and reinforce awareness training in several different modes.

And when it comes to security awareness training, your fellow C-suite executives should not be excluded. They have access to very sensitive information and are prime targets for spear phishing attacks, so they need to know what the threats are and what to do about them. Of course, their training might be private and condensed, but they need it just the same.

It all starts with data classification

When it comes to security awareness, it all starts with data classification—recognizing where data is in the company, and knowing what data needs to be protected. Here’s a great example of why this is so important:

In March 2016, the Internal Revenue Service issued an alert to payroll and HR professionals about a phishing scam that was hooking a lot of people (and still is). The scheme involves sending an authentic-looking email that appears to come from the recipient’s CEO, but is, in fact, spoofed. The message instructs the recipient to send “the CEO” confidential information on all company employees, including name, birthdate and social security number. Dozens of companies have fallen victim to this attack. Why? Because the email recipients who complied with the bogus request failed to view the requested information as something that was valuable, confidential and in need of extra special protection—even if it is the CEO who seems to be requesting it. The recipients simply viewed the data as something they had access to in their job, and sent it without consideration for the need to safeguard confidential information.

Security awareness is more than just how to behave; it’s how to think about the data you are responsible for. People need to learn data classification in order to understand proper care and treatment of the data, and awareness training needs to set the stage for this.

If you see something, say something

We can all take a lesson from the law enforcement community to promote a “see something, say something” mentality. Teach people to report all suspicious activity. For instance, you can set up a special email address where people can forward messages they suspect to be spam or phishing messages. Then be sure to acknowledge their submissions. When people get positive reinforcement for their diligence, they become part of your “neighborhood patrol” team. They’ll keep their eyes and ears open for suspicious situations and report them. While people reporting spam rarely results in actionable information, it does increase  people being on their guard for things that just doesn’t look right.

At the same time, let people know that they won’t be blamed or punished for an accidental or inadvertent action that leads to a security incident, such as clicking on a phishing link. People must be encouraged to report rather than hide incidents – even if they initiated it – so the events can be quickly investigated and mitigated.

Most people really do care about protecting their company. They want to do the right thing. The biggest challenge is making them see cybersecurity in the same vein as physical security. They wouldn’t leave the door propped open and leave their wallet right out on the desk. They might leave the door propped open but they’d take their wallet with them. Or, they might leave their wallet on the desk but they’d make sure that the door is locked. The same holds true for data security. Explain why they wouldn’t want to leave a sensitive database open and walk away from their desk. The database is like the company’s wallet – full of important stuff – so they should close the database and log off the application so no one else can access it without authorization.

Communicate, but don’t overdo it

Fun contests, incentives, awareness fairs, newsletters and other internal media campaigns all are good for bringing attention to security. Use group activities to raise awareness or reinforce a security culture. An individual’s identification within a group is a strong driver to behave in a directed way.

If you do a quarterly newsletter where you provide security pointers, try to tie it to what’s going on in the world or the company. Use real and relatable examples. One CISO says he did a “back to school” themed newsletter that he published in September. Everyone can relate to the excitement of “back to school” whether they have children or not; all of us went to school. His newsletter welcomed everyone back to the virtual classroom where they would learn about the ABC’s of, say, protecting login credentials. It was a fun way to tie the content to the time of year and get people to relate.

The messages of such programs need to be repeated in varying ways to help employees absorb and internalize them—but don’t do it too often, or people might tune you out. You want to make sure that people pay attention to critical communications from the security program when you need them to.

Conclusion

Security awareness training can’t be a once-and-done activity. The best programs engender a corporate culture of security awareness, meaning that people accept “this is the way we do things” and it becomes second nature.

The post How to Get Everyone Attuned to Cybersecurity: Ways to Raise Security Awareness appeared first on Security Current.

For the third straight year, Drs. Daniel Solove and Paul Schwartz held their Privacy and Security Forum at George Washington University Law School. For the third straight year I attended and presented. This year’s forum was the biggest ever and like the previous years, was packed with different sessions on issues ranging from GDPR to Industrial Control System security.

Dave Tyson of CISO Insights and I spoke about Governance. We focused on how the Security function fits within the business by means of Governance activities.

Defining governance is tricky so we started with the justification for it. Why governance?

Governance enables organizations to:

• Ensure senior management direction is applied to security risks
• Make risk/investment trade-off’s
• Meet their fiduciary responsibility for oversight
• Create an ongoing communication process to continuously improve

Moreover, organizations with top tier risk management programs are also the most profitable businesses.

Having gone into each of these points for a bit, we still had not defined governance and had not yet dropped the bombshell that really effective governance means seemingly taking the CISO down a notch.

So, we presented some framework level definitions as a baseline:

• ISO 27001: 2013
  • 3 Management review: Top management shall review the organization’s information security management system at planned intervals to ensure its continuing suitability, adequacy and effectiveness.
• NIST Cybersecurity Framework
  • Governance (ID.GV): The policies, procedures, and processes to manage and monitor the organization’s regulatory, legal, risk, environmental, and operational requirements are understood and inform the management of cybersecurity risk.

Governance is about management and it’s about risk and it’s about risk management—all three (and they can be seen as discreet). So, not surprisingly, when you dig deeper you start thinking of governance not just as a top down activity but as something that can serve both strategic and tactical objectives (in ISO terms: “suitability, adequacy and effectiveness”). Grabbing the Risk Management graphic out of the NIST Cybersecurity Framework, we annotated it to indicate the different spots where governance should occur.

A traditional view of governance has it occurring only at the Executive level. But Senior Directors who are business process leaders also can have a role in governing the security function, even if their authority leaves them more as advisors than approvers. The business process level is where effectiveness is measured and therefore managed/governed at the tactical level. This assumes that management within the enterprise is collaborative.

Regardless of level, governance succeeds when it is a crucial input to the management of the Security Program. In order to accomplish this, governance bodies need more than just metrics and discussion topics. They need to be allowed to have input into the agenda and priorities of the Security Program itself.

Too often, the Governance function is reduced to approving budgets for Security. Too often, the CISO alone sets the agenda for the Governance Committee meetings. And way too often, while resources and project plans are presented to Governance Committees, the operational side of the Security Program is left un-discussed.

And so, Dave and I argued, you have to, in a sense, demote the CISO. Or more accurately, charge them with involving key stakeholders in shaping the Security Program at an organization. For the “command and control” type of CISO, this collaborative approach may be difficult to adopt.

Certainly, there is a technical side of the CISO’s role that is best left outside the Governance Committee meetings as well (regardless of what level the members are at). For example, I once heard a CISO explain how he had been telling a CFO why different 802.11 wireless protocols were better than others.  He did not last long at that organization.

But assuming the right level of discussion, the CISO’s role is to engage the organization in all aspects of security. And for that to happen, they need to allow those involved in governance actually govern.

The post Demote the CISO appeared first on Security Current.

In my 10+ years as a CISO, I’ve noticed a trend that appears to only be increasing. What I have observed is a proliferation of job titles that rhyme with CISO. But rather than describing the Chief Information Security Officer, these new titles swap out the word “chief” and come up with something else to describe something different.

There’s the BISO, or Business Information Security Officer, who has some level of responsibility for a specific part of a firm’s business. They are expected to be part of the business unit they are responsible for. In other words, knowing the business is as important as knowing security.

The BISO is not to be confused with the TISO, or Technical Information Security Officer. This individual is more technically focused and might serve multiple BISOs in complementing the BISO’s business acumen with their technical expertise.

You might see a Network Information Security Officer, or NISO, where the word “network” can mean minding security for layers 1 through 4 of the OSI stack or refer to the NISO being a kind of mega-BISO who takes care of an interconnected group of business entities within a complex Enterprise.

If the business is divided into divisions, you might find a DISO and, likewise, if the structure is regional, you might find a RISO. To be fair, I’ve never seen a RISO title. Usually, the regional security heads are called by names like “CISO for EMEA” or “Deputy CISO, APAC region.”

And then there are the companies that are bashful about appointing a CISO and give their head of Information Security titles like “Director of Information Security.” To them we say, either call that person a CISO – and give them the commensurate responsibilities – or go get one. As I’ll argue below, there’s something that can get missed in this game of “ISO scrabble.”

Some CISOs I know responded to this sprawl of ISO job titles by adding “worldwide” or other descriptors as a preface to their title. After all, there should be one Chief and it is important to make sure that there is no confusion about it.

Human Resources, Executive Management, and sometimes even the Board has a direct say in all of this, of course. We can’t simply pin the existence of so many ISOs on the CISO. In fact, some of these ISOs might not report directly to the company’s CISO. Sometimes, there are so many dotted lines, you’d think that the org chart was printed out on an old, cheap dot matrix printer.

The first thing to emphasize about this jumble is: there’s more than enough work to go around. Call yourself Dr. Faustus for all anyone cares, just protect the Enterprise. Organizing that work is one reason these sub-CISO titles came into being. The titles legitimately describe and put limits on a function. You, X-ISO, need to focus on “X” and leave the rest to someone else (Y-ISO, Z-ISO, etc.?).

Then there’s the need to satisfy the ambitions of people with these positions. Consider it a compromise between where they are and where they want to be. “You are not the CISO, but, hey, this is close to being the CISO (just squint when you read your business card).”

Ending job titles in “Information Security Officer” is attractive to everyone involved. The security frameworks (ISO/IEC 27001:2013: 5.1 and 5.3 and NIST Cybersecurity Framework ID.GV-2, for example) all demand that roles and responsibilities be defined such that  people are committed to staffing the security program. And nothing says commitment and, as applicable, compliance better than dedicated resources, and nothing says Information Security resources are dedicated better than making them Information Security Officers.

Now I’ll get to the point.

I would argue that the letter at the END of the acronym is way more important than the letter at the beginning. It’s the “O” for “officer” that matters most. Being an “officer” needs to mean something.  This is where things get lost and too fuzzy sometimes.

It is important that people manage processes and teams. When they do that, regardless of their title, they are “managers.” It is important that work is directed and prioritized. People who do that are functioning as “directors.” People with the title Manager or Director can be at any level in the organization. Of course, there may be job classification schemas in an organization that dictate where they fall, but the functions do not limit the level. Likewise, being an “officer” does not mean you are at a particular level.

What being an officer does mean is that you are responsible for the objectives of the security program. Sometimes that means you manage, sometimes you direct. Sometimes you analyze, sometimes you observe and sometimes you consult. Sometimes you approve and sometimes you reject policies and their exceptions. Sometimes you might roll up your sleeves and configure a firewall (hint: “permit ip any any” is bad).

Being an officer should mean that the objective is more important than the tasks at hand. You can’t stand on ceremony if your job is to stand between the threats and what you’re protecting. The Information Security Officer owns protecting the company’s information assets. If a vulnerability or risk to the organization and the assets you’re protecting is in your view, then it is in your purview.

If an organization wants someone to solely manage a team or process, then they should call that individual an Information Security Manager. If they want someone to solely direct a function or set of functions, then they should hire an Information Security Director. If, on the other hand, they decide someone should be called an Information Security Officer, then expect and accept that that person’s scope goes beyond just managing or directing.

There might be more important organizational considerations when evaluating the security function in an Enterprise. “Who does the CISO report to” is discussed a lot more than who has what job title. But to the extent that job titles reflect roles and responsibilities, it’s worth considering just what makes an “officer” an Officer.

The post Rhymes with CISO appeared first on Security Current.

I have gone back and forth for a long time.  Should security be risk-centric or data-centric.  Outside of security professionals, you sometimes meet people who believe security should be compliance-centric and others who believe security should be audit-centric (which is a type of compliance-centrism).

Certainly there used to be network-centric views of security but they have mostly eroded in the face of mobile devices and the rise of cloud applications.

So, what is or should be at the center of security?  To some extent, the point might seem silly.  Who cares what you put at the center of your security program so long as there are no breaches of confidentiality, integrity and or availability?  Protect the enterprise and you can put a vase of peonies at the center of your security program for all the enterprise cares.

But it matters.  At least when comparing the same level of effort.  In other words, the best compliance-centric approach will out shine a data-centric approach that is pursued with significantly less effort and half-hearted organizational commitment.  Which is a long way to saying “all things being equal” what an organization puts at the center of its security program makes a difference.

And in saying there even is a center, I am implying that we look at things with perhaps too strong a bias towards one thing or another.  After all, the most risk-centric approach still emphasizes compliance and data protection.  But it matters.  The center is the focus you start with and the one you return to when re-evaluating a program.

Below is a look at the features and limitations of each approach ending with the conclusion that the only “centrism” that provides complete security for the enterprise is people-centric security.

Compliance and audit-centric: Has enough been written about how “check the box” security programs lead to security product shopping lists, policies that no one reads and surprised executives when a breach occurs (“but we were PCI compliant”)?  Maybe, but on the other hand there’s a thin line between a strong compliance program and implementing a robust security framework.  And if you’re in a regulated industry, being non-compliant cannot be an option.  So as a security professional, the best thing to do when faced with executive insistence on such an approach is to make sure there is a general understanding that being compliant and being secure are not necessarily equivalent.

Location-centric:  This form of security is largely obsolete but is making an interesting limited comeback with the advent of geo-fencing.  In this view, the perimeter is absolutely the most important focus of controls with tight control over access/ingress being critical.  Authentication is based, first and foremost, on “where you are” (what I have elsewhere called the fourth factor of authentication).

It sounds great but it has limits and can lead to a false sense of security.  Developers, especially those who work on applications that are primarily internally facing, have been known to rely on this approach to avoid building tight security into their apps. (“It’s not accessible to the outside, so your firewall is protecting it.”)  While this might have served as adequate in the days prior to the internet, the interconnectedness of things make this approach insufficient to shape a program around.  Which suggests a broader view.

Network-centric: In this approach, there is acknowledgment that location/perimeter is not a sufficient center to build a program around, but the “network” is.  The network comes to be defined as all the connections that might touch the enterprise and so third party management becomes important.

Mobile devices are part of the greater network so they also need to come under control.  The limitation of this approach is that threats can come from outside the network in ways that the network-centric approach cannot control.  Paper documents, for example, can lead to breaches, especially of discreet information.  And while a print-out of 80 thousand names and credit card numbers would be unwieldy, misplacing it would be considered a breach of highly confidential information nonetheless.

In addition, a lot time and energy goes into the ongoing definition of what exactly the network consists of and that can be an exploitable vulnerability in and of itself (deception based threat detection technologies are the latest attempt at addressing this).  Which suggests a different emphasis:

Data-centric: Even I like this one (and I’m hard to please).  Whatever media they are on, whatever network they traverse, wherever they are, data are valuable.  Protecting information seems comprehensive and, at first glance, does not take nearly the effort to define.   Data are data, yes?  Everyone knows what information is.  With an emphasis on access control and data classification procedures, data-centric security can be effective and efficient.  Are there still weaknesses to this approach? Yes.  The two most common are:

1.Not knowing where you have data.  A multi-million dollar HIPAA fine against a New York hospital that was protecting data just fine with the exception of that researcher’s PC under his desk with the thousands of patient names and access to the internet is a stark example.  It’s hard to know where all the data are and it is usually impossible to fully control every single place it ends up (consider if most organizations could ban ALL email attachments for example).

2.Data classification is hard.  When you consider that information someone makes publically available on LinkedIn may still qualify as “personal data” in the EU and require special handling, you can see the difficulty a data owner might have.

In addition, data classification and access control is ultimately situational and that is a slippery slope.  For example, most people would agree that if someone shows up unconscious at an Emergency Room,  those treating them should have access to every damn bit of information on that person they can find (sometimes referred to as “break the glass” data access in the jargon of medical records privacy).  People are a bit less certain about whether an insurance salesperson should be allowed to learn from the DMV that you own a motorcycle so they can target you for motorcycle insurance.

Risk-centric: “Risk based.”  That’s the phrase that pays in the sense that nothing helps justify investments in security better than showing the investment mitigates a significant risk.  And, after all, given limited resources, you pretty much have to prioritize how you use them based on addressing what you deem to be the highest risks.  The limitation with this approach is that while you can define the enterprise’s data and business processes sufficiently to have a very good handle on impact, the other factor in measuring risk, likelihood, is a lot harder to nail down.

In fact, we know (most recently from the recent WannCry exploit) that those that design exploits are always looking for the weak spot that assessors deem “least likely” to be exploited.

In other words, the data-centric approach to security will help you zero in on what you have to loose and the risk-centric approach is invaluable in helping you prioritize resources around that.  However, each are still just narrow views.  Undeniably essential views, but narrow ones nonetheless.  That’s why my new allegiance is to a people-centric view of security.

People-centric: Hamlet said “O, that this too too solid flesh would melt.”  But till it does and we’re all virtualized, people are going to hit keys, respond to emails, click on stuff and answer the phones in a free-form and random manner.  It’s not an original thought that people are a major vulnerability in a security program.  From the far less Shakespearian quotation “there’s no patch for stupid” to the tongue in cheek label of an “ID-10-T error” all the way to descriptions of users as the “weakest link,” us people have gotten a lot of bad press.

In spite of all that, people are also a huge strength.   There are specific processes that succeed or fail depending on how well people perform.  In addition, there is no realistic way to use optimize security controls as business enablers without buy-in from business stakeholders.

Consider security awareness training.  All strong programs have a robust ongoing awareness effort.  It is essential.  These efforts are usually framed in the context of making sure the workforce understands its role in ensuring that the enterprise is secure.   If you’ve evaluated training programs you notice some interesting things about them.  First of all, they tend to present security as a responsibility that the user has to the organization (“Here’s what you can do to keep our data secure”).  Second, they sometimes have needlessly technical explanations in them (this is often true, for example, when a training module tries to engage the student on the subject of encryption).

Imagine training that took a different approach.  Instead of the compliance-centric “Here are your obligations under the regs” or the more colloquial risk-centric “We need your help in managing the risk faced by our organization,” what if there was a people-centric approach?

Imagine training starting out with this pitch: “We know you have a job to do and that you don’t want it interrupted by having to spend time on security, so we’ve put together this course to give you the tools you need to do your job safely.  Just like you’d put on a hard hat to go into a construction area, we have controls that provide you with the way to stay safe in cyberspace.”

Firewalls and SPAM filters?  Most of us, when confronted by a disgruntled user who had something legitimate blocked, already have an explanation that focuses on their safety.  If you don’t have one and are still using the “We need to keep our data secure and if that means blocking some legitimate things that’s the price we have to pay” then I would suggest you change it.

Encryption?  If you have to talk to a user about it, maybe you didn’t implement it seamlessly enough.

Selling safety as the goal of security is the easy part.  The tricky part is getting the user engaged in being an even more active participant in the security program.  To get the full value of partnering with your users in a people-centric security program, you need to make some adjustments:

1.Start thinking about security as a way to keep the workforce safe (we just talked about this).

2.Get over the idea that false positives are to be avoided: remember that the boy who cried wolf may have had some character flaws but the entire town made a decision to leave the boy, a detective control, in place and then to ignore him.  Refine your alerting, but do not be hostile to a false alarm.  And be sure  to encourage users to come forward with things that they observe that concern them.

3.Be sure your mission is to serve the business and challenge any part of your program that does not directly do that.  First and foremost, governance is about playing by the rules.  Just make sure the rules support the objectives of the organization they are designed to govern.  This does not mean that you need to make sure everything you do is popular (that’s not going to happen) or that compliance should be optional.  But it does mean that if you can’t explain to a reasonable business stakeholder why a control is part of your program, then you need to re-think the control or refine your explanation.

4.Recognize that success is silent and failure screams.  How many times a day do people in your organization NOT click on a malicious link and refuse to initiate an emergency wire transfer?  How many times do they hang up the phone when someone on the other end says they are “John from the help desk”?  How many are NOT pursuing that generous offer from that Manipulatistan finance minister to give them 10% of 100 million Euro in exchange for helping them get the money out of their capital, Scamsburgh?  there’s no way to know for sure.  But you have to realize it is happening all the time.  For every one person who clicks on the link for naked pictures of Celebrity X and thereby downloads ransomware, there are at least ten who don’t.  People ARE a strong preventive control and the more tools you put in their hands, the stronger they will be.

The people-centric view of security needs to evolve.  People need to be seen as the strongest control and not the greatest weakness in a security program.

The post What Is at the Center? appeared first on Security Current.

CISO

Security professionals feel no great joy in being right about patching.  The past two months have been a period of “I told you so” moments for anyone who has ever had to have the conversation with a sys  admin about the importance of patching. It’s been a long time for me but the memory lingers.)

Still  security professionals care more about being safe than being right so, as I say, there’s no great joy.  But, now that we’ve had two months of ugly exploits that were very much enabled by unpatched systems and everyone appears to be paying attention, we should take a few moments to review the excuses we’ve heard for why it was not important to patch.

We should be able to finally de-bunk the excuses and I think I speak for everyone in security when I say we hope to never hear them again.  Consider this a proactive set of canned responses to be used to reply to sys admins and their managers who, at some future time, somehow forget about the WannaCry-Petya attacks.

1. “Patching takes time and my staff is busy.” So the question then is: are you sure keeping the infrastructure secure is part of your department’s mandate? Go check.  If you did check and if keeping the infrastructure secure is not included in it, then find the folks who are responsible for keeping the infrastructure secure and make sure they’re patching. But, on the other hand, if keeping the infrastructure secure IS your responsibility then the question becomes: does your staff have something more important to do and who made the decision that it was more important than patching?  Perhaps the person who made that decision should reconsider.  Finally, if keeping the infrastructure secure is not anyone’s responsibility, jump up and down waving your arms until it is.  Security will be there jumping up and down  and waving with you.
2. “These machines don’t connect to the internet so they don’t need to be patched that often.” These latest attacks made it abundantly clear that malware is capable of spreading like a weed. And it doesn’t matter if the weed first started in your neighbor’s backyard; once it jumps to yours, anything can happen. Not to mention the fact that some of your most important machines may not ever connect to the internet but may bring the business to a halt if they get infected. So maybe whether or not something connects to the internet is not as important to patching as whether or not something is important (or connected to something important).
3. “Patching can break something.” You mean what if patching breaks a test machine as opposed to not patching and finding that an outbreak of malware was so severe that you have to send everyone home?   Patches should be tested.  If patches DO break something on a test machine, then some level of effort or risk must be taken on.  But make those decisions explicit, not a matter of inertia.
4. “My staff will get to patching as soon as they’re done with the nextthingmobilecloudIOTbigdata project.” Patching is boring.  When faced with the choice between working on that sexy new deliverable that is super high profile and patching the system, we are all tempted to work on the shiny stuff.  See #1 above for more on this.

Security and IT Ops are good partners in most organizations but the time and attention commitment involved in  patching often challenges IT Ops who are being asked to make EVERYBODY happy.  If there is one learning that came out of the past two months it’s that your organization de-prioritizes basic system hardening at its own risk.  And if anyone wants to understand just what that risk is, they can type “WannaCry” in their search engine of choice and hit ENTER.

The post Patch Yours appeared first on Security Current.

In this series I take a close look at the Framework for Improving Critical Infrastructure Cybersecurity which NIST first published in February of 2014. Read Part One ‘All Infrastructure and the NIST Framework’ and Part Two ‘Hackers Are Not Afraid of Frameworks.’

There I was preparing part 3 of my close reading of the 2014 Framework for Improving Critical Infrastructure Cybersecurity from NIST and then I realized it was almost three years old. Soon, it will be under a new administration and version 1.1 is due for release anytime. So, if I intend to be ruled by the “current” in Security Current, I needed to wrap up my treatment of 1.0 quickly and make what follows more broadly relevant.  I must go beyond version 1.0.

What follows are some impressions of 1.0 that hopefully do just that.  The series will resume when 1.1 is released.

1. The Gaps

While analysts and engineers might agree that gaps are a measurement of the distance between what is and what should be, here I am defining a gap as both an expression of dissatisfaction and a recognition that assumptions are being made.  These are instructive.

As I’ve already discussed, 2014 Framework for Improving Critical Infrastructure Cybersecurity  is a bit murky.  It does not actually define what a framework is, for example and it relegates the description of what it terms its “Core” to an Appendix that is as long as the rest of the document .  It defines its “why” in the introduction and its “how” in the Framework Core (a well ordered and presented list of more or less familiar controls).

Then there is something in between the descriptions of the why (pages 1-7) and the how (18-35).

Placed squarely between the purpose of the NIST Cybersecurity Framework and the Framework Core are the components of the Framework that were designed to connect the why and the how.  These are the Framework Implementation Tiers and the Framework Profile, the schematics for achieving the Framework Core’s more specific objectives.  For lack of a more accurate description, the Tiers and the Profile are the “what.”

This is the murkiest part of the document.  Descending from the HIPAA Security Rule’s Flexibility of approach[1], this section at once tries to define how to approach evaluating and improving cybersecurity while allowing that even within a single organization, there is probably no single right answer.

It recommends at least two profiles (current and target) but allows that two is a minimum: “Given the complexity of many organizations, they may choose to have multiple profiles, aligned with particular components and recognizing their individual needs” (page 11).

That’s not to say that those 11 pages between 7 and 18 are not useful.  They are.  They are also striking in a number of ways.

2. The Tiers

The Tiers are most likely more familiar to most readers than the Profile as they resemble maturity levels from other frameworks such as COBIT.  And although the document is explicit that the Tiers are not maturity levels, it does not make clear why not and, for that matter, why bother making the distinction (there’s that murkiness).  The argument seems to be that using the Tiers as maturity levels would somehow weaken the concept of the organization’s Profile:

Tiers do not represent maturity levels. Progression to higher Tiers is encouraged when such a change would reduce cybersecurity risk and be cost effective. Successful implementation of the Framework is based upon achievement of the outcomes described in the organization’s Target Profile(s) and not upon Tier determination. (page 9)

In other words, basing a program on the Tiers might distract the organization from using the profile building methodology.  The profile building methodology emphasizes implementation.

Regardless of what we call them, the description of the tiers is striking because of what they are missing.  They do not allow for a zero.  Tier zero is literally missing.  That is, the Tiers do not allow that there are absolutely no information security controls protecting the Enterprise.  This is startling, but also highly accurate.

This lack of a tier zero is ground breaking.  It is a recognition that by 2014 security was sufficiently built into infrastructure, operating system and application product designs that having an environment with no controls is virtually impossible.   It challenges organizations to identify and control the procedures and technologies that must, even to some limited extent, be in place.

The four tiers that are defined follow a familiar path from tier one where controls are mostly out of control to tier four, a fully governed program that can adapt to a changing threat landscape and technology environment.

Another striking thing about the tiers is that they describe activities but only vaguely define who would perform them.  The “organization” is mentioned eight times as being the one to perform cybersecurity activities.  Management, personnel, staff and partners are all mentioned once as entities that perform some action.

This lack of definition of a staffing model or named roles within the organization ties back to NIST’s avoidance of a one size fits all approach.  It is only important to note that while the document gives us guidance on why, what and how, there is barely a hint of who will improve the cybersecurity of the nation’s infrastructure.

3. Profiles

The Framework allows organization’s the opportunity to reach a rather dramatic conclusion “An organization may find that it is already achieving the desired outcomes, thus managing cybersecurity commensurate with the known risk.” (page 13).  I discuss how dangerous this attitude is in The Winter of our Discontent.

To summarize it here: when you reduce cybersecurity to a checklist of controls and let what’s left be defined as “known risk”, you create a risk within the organization that the organization will become complacent, content with its own efforts.  NIST addresses this by proposing the concept of the current and target profiles.   Again, however, what’s missing is the “who.”

Who drives the organization to the target profile?  Who is charged with not allowing the target profile to get stale?  This is the role of the security professional and it is unfortunate that is not more clearly spelled out in the document.  To be fair to NIST, while the document is murky on this, NIST itself in the National Initiative for Cybersecurity Education (NICE) is certainly doing its part to address the “who.”

The consummate security professionals are not qualified because they may understand in detail why there is a DES encryption algorithm and a triple DES encryption algorithm but no double DES encryption algorithm, but because of a different quality altogether.   Call it their penchant for “dissatisfaction.” Security professionals are the most important actor in assuring the security program is up to the challenge of defending the organization.

4. People

The most overlooked component of a security framework is the professionals that implement and maintain it.

The Security professional protects the infrastructure and the data.  That’s the job.  And it doesn’t matter if we are looking at a Network Security Analyst whose tasks are narrowly focused or a CISO who is accountable for the entire Enterprise (“the Bitcoin stops here”).  Protect the data.  Protect the infrastructure.  Keep the secrets secret.  That’s the job.

And if there were certainty in delivering that service to the Enterprise, then the Security Professional could put their head down and get on with it.  But we can’t.  Our heads cannot be down.  They have to be “on a swivel” because in this world, we can modify the old adage and say that the only thing certain is death, taxes and cyber-attacks.

In other words, the job includes never being completely comfortable defining the limits of the job.    When they found this diversity of focus, the National Research Council’s Committee on Professionalizing the Nation’s Cybersecurity Workforce reached a few odd conclusions in their 2013 report, Professionalizing the Nation’s Cybersecurity Workforce? Criteria for Decision Making:

Conclusion 3. The cybersecurity workforce encompasses a variety of contexts, roles, and occupations and is too broad and diverse to be treated as a single occupation or profession. Whether and how to professionalize will vary according to role and context.

Conclusion 4. Because cybersecurity is not solely a technical endeavor, a wide range of backgrounds and skills will be needed in an effective national cybersecurity workforce.

In fact, the workforce should never be fully professionalized in the classic sense.  “Broad and diverse” is exactly what is needed in a security professional.

The post NIST Cybersecurity Framework, Beyond Version 1.0 – Part 3 appeared first on Security Current.

Read Part One All Infrastructure and the NIST Framework. In this series I will take a close look at the Framework for Improving Critical Infrastructure Cybersecurity which NIST first published in February of 2014.

Is that news?  No, of course it isn’t.  In fact, deterrence (fear) may seem like an odd concept for cybersecurity. Arguably, except for highly visible physical access controls, virtually all other cybersecurity controls are designed to keep an incident from happening (i.e. protective/preventive) or detect and then respond/recover when it has.

A guard with a gun.  That’s deterrence.  An armed guard standing next to a metal detector between the thief and the elevators to your office may convince the thief to try the building down the street.  But as anyone who has looked at the logs of what hits an external facing firewall on a daily basis knows, “they” never stop trying to get past that wall and “they” are not deterred just because you have a good, well managed firewall installed.  So, deterring attackers is not at the forefront of cybersecurity efforts.

Individual controls can be described as protective, detective and/or responsive.   A framework itself, however, should serve some other purpose.   Deterrence would be really great.  Imagine putting a seal on your web site saying you were “protected by the NIST Cybersecurity Framework” and having that keep hackers away.

But it doesn’t work that way.  As Frank O’Hara pointed out in 1961:

If someone’s chasing you down the street with a knife you just run, you don’t turn around and shout, “Give it up! I was a track star for Mineola Prep.”

You can implement every control in a framework without implementing the framework itself.   So, if implementing the framework is not a deterrent, then what justifies the overhead of putting a framework in place?

There is definitely overhead in implementing a framework.   The example that the NIST framework provides of using the framework (section 3.2) lists 7 steps.  Each requires resources.

1.Prioritize and Scope.

2.Orient.

3.Create a Current Profile.

4.Conduct a Risk Assessment.

5.Create a Target Profile.

6.Determine, Analyze, and Prioritize Gaps.

7.Implement Action Plan.

Other methodologies limit themselves to 4, 6 and 7.   This is either because the framework is “baked” into a regulation that tries to not be too proscriptive (i.e., the HIPAA Security Rule) or because controls are listed separately from implementation (PCI DSS is mostly that).

Some organizations will outsource step 6 (and the entity they outsource to will either implicitly or explicitly perform step 4).  Once they have a list of prioritized gaps, the organization sometimes appoints a project manager as their CISO to carry out step 7 (I vehemently argue against this approach in an earlier Security Current article: No Book to Be By).

We will look at the specific 7 steps in a later article.  Here, let’s concentrate on why do we need a framework (and briefly why this one?) and what is a framework anyway?

Here are the short answers followed by some explanations:

Why do we need one? We need a framework to win arguments and answer specific questions.

Why do we need this one? There’ll be a more substantive answer at the conclusion of this series.  For now, here’s a brief, if superficial one: the President said we had to have it and made supporting it “voluntary” (Section 8. Executive Order 13636, “Improving Critical Infrastructure Cybersecurity,” issued on February 12, 2013).

What is a framework? We don’t know but we know one when we see one.

Why do we need a framework?

I. To win arguments

Anyone who leads a cybersecurity effort at an organization is familiar with the two most common types of resistance to their efforts that are not directly related to budget: “it will impact performance/service delivery” and “show me where it says we have to do that.”

I have had large application vendors tell me they cannot encrypt sensitive, regulated, personal data because it will make performance unacceptable.  When asked for any measurement to back up that claim, they demur.  When asked how fast a CPU would need to be to compensate for this encryption caused “performance hit,” they explain they do not have that level of detail.

The CISO’s push back to the “performance hit” argument against security controls is to reduce it to real measurement.  The “performance hit” argument gets validated or debunked pretty quickly in the face of data.

The same argument for encryption holds true when there are “performance hit” arguments against process changes, logging, filtering and monitoring.  The successful CISO answers those with patience and with reliance on actual metrics.

But the “show me where it says we have to do that” argument against a security control is a bit trickier to respond to.   With the exception of specific regulatory requirements, mapping a detailed control to a standard usually takes some explanation, research and collecting standards from various sources.

The NIST Cybersecurity Framework describes its role in making sense of this as follows:

The Framework relies on a variety of existing standards, guidelines, and practices to enable critical infrastructure providers to achieve resilience. By relying on those global standards, guidelines, and practices developed, managed, and updated by industry, the tools and methods available to achieve the Framework outcomes will scale across borders, acknowledge the global nature of cybersecurity risks, and evolve with technological advances and business requirements. (NIST Cybersecurity Framework, page 4)

Without a framework to help out, mapping a whole collection of controls to “a variety of existing standards, guidelines, and practices” would be a nightmare/quagmire.

And it is not just the CISO that needs help responding to the “show me” argument.  CISO’s have allies in an organization these days.  Supportive executives and managers outside of the security organization are most effective at helping the CISO when they have external validation to back them up.

These partners in building a security aware culture are often general counsel and facility managers, but they can also be board members, executives and managers that have thought through the risks and want to avoid them.  They want to support the CISO.  They do not want to get “that phone call” notifying them of a breach.  They need help.

They find themselves in meetings being asked why we need to spend money and/or change the way “we’ve always done things” and it is best if not every justification comes down to a mixture of “because the CISO said so” and “we don’t want to be the next headline.”

Frameworks serve as an effective document to structure the argument.  Those who might resist the implementation of a particular security standard find it difficult to argue against the idea being thorough.   It is useful to have an externally validated document to work from in justifying the program.  The NIST framework is that kind of document.

To put it another way: in an organization that accepts the mission of security, a thorough, externally vetted approach such as the NIST framework is hard to argue against.

II. To answer specific questions

One question a framework answers is “can you show me where it says we have to do that?”  — that question is usually asked as an argumentative challenge by someone resistant to a security control.  The next question a framework helps you answer, however, is usually asked more from a sincere desire to know the answer. Executives and Boards are asking this question with increased regularity.

That harder question is “are we secure?”

Security personnel at all levels stumble on this one all the time.  Answering “no” is a tempting mistake—after all, if you say “yes” then you risk looking wrong if your organization is breached.  Answering “it depends on what you mean by secure?” is at best career limiting and at worst will be seen as a passive aggressive equivalent of “talk to the hand”.  You need something else.

You can tell the story that Gregory of Tours told in the 6^th century.  The fortress of Vitry was secure.   King Theuderic wanted to defeat the nobleman Munderic, who was barricaded inside it.  But no one could breach the walls.  So the King just had someone promise Munderic that they would not kill him if he came out.  And just like a too-trusting user clicking on a malicious link that makes unrealistic promises, Munderic came out and was promptly killed.

Perhaps the best answer to the question “are we secure” is this: “we can measure how comprehensive and responsive our security program is but security is like health, you do what you can to maintain it but you are still at risk for incidents despite your best efforts.”

You cannot give that answer, however, if you are not prepared to provide a comprehensive framework against which to measure what you’re doing.  In fact, as we will see in the next article, this is where the NIST framework steps 1, 2 and 3 are the most valuable.

What is a framework anyway?

Look up the word “dictionary” in a dictionary and you will find something more than the phrase “you’re looking at it.”  But look for a definition of a framework among the NIST world and you will be hard pressed to find much more than that.

In the NISTIR 7298 Revision 2 Glossary of Key Information Security Terms (2013) we find only one definition of one particular type of framework:

Risk Management Framework – A structured approach used to oversee and manage risk for an enterprise.

Like many of the definitions in NIST’s glossary, that definition originates from the Committee on National Security Systems National Information Assurance (IA) Glossary (CNSS Instruction No. 4009, 26 April 2010).  The word “framework” is not itself defined.

Is that all a framework is: a “structured approach”?

In the Executive Order of 2013, the President and his advisors came close to a functional definition of the framework they expected:

The Cybersecurity Framework shall focus on identifying cross-sector security standards and guidelines applicable to critical infrastructure. The Cybersecurity Framework will also identify areas for improvement that should be addressed through future collaboration with particular sectors and standards-developing organizations. To enable technical innovation and account for organizational differences, the Cybersecurity Framework will provide guidance that is technology neutral and that enables critical infrastructure sectors to benefit from a competitive market for products and services that meet the standards, methodologies, procedures, and processes developed to address cyber risks.

A framework is, in fact, more than a structured approach.  It is the structure itself.  A conceptual framework is, as its physical counterparts are to components, a way to arrange a set of ideas in such a manner so as to clearly describe their relationships.  In the next article, we’ll look at how the NIST framework, by introducing “tiers” and “profiles” has created a comprehensive set of relationships and how those can be used as the central tool in securing the enterprise.

The post Hackers Are Not Afraid of Frameworks – Part 2 appeared first on Security Current.

Each infrastructure is critical to someone.  Go ahead: ask a CIO if they are in charge of something other than “critical infrastructure” and see what they say.  In fact, the increasing criticality of all aspects of infrastructure underlies all our assumptions about security and privacy.

This article is the first in a series where I will take a close look at the Framework for Improving Critical Infrastructure Cybersecurity which NIST first published in February of 2014.  In challenging and reframing some of the assumptions in the document, I hope I can be forgiven for completely ignoring the idea that there might be “non-critical” infrastructure that would not be in scope.  The document’s own statement for its importance, its preamble, is somewhat narrow and misleading:

“The national and economic security of the United States depends on the reliable functioning of critical infrastructure. Cybersecurity threats exploit the increased complexity and connectivity of critical infrastructure systems, placing the Nation’s security, economy, and public safety and health at risk. Similar to financial and reputational risk, cybersecurity risk affects a company’s bottom line. It can drive up costs and impact revenue. It can harm an organization’s ability to innovate and to gain and maintain customers.” (page 1).

The impact statement is undeniable.  Bad things can happen if we get hacked and stuff gets compromised.   The statement is misleading because it insists on convenient buckets in which to put things.  The folks at NIST are, to a large degree, taxonomists and like Linnaeus before them, that approach has strengths (as we will see later in the series) and weaknesses (as we will see below).

The most apparent flaw in the above is the distinguishing between cybersecurity, financial and reputational risks.  For any given control and the risk it mitigates, we can identify which of those three are primary, but taken at the macro level, these three risks are inseparable.

If cybersecurity risk “can drive up costs and impact revenue” then how do we separate it from financial risk?

If cybersecurity risk can negatively impact an organization’s ability to “gain and maintain customers” then surely it impacts reputation risk.

And, conversely, companies at increased financial and/or reputational risk may invest too little in cybersecurity and/or be too desperate to take the time to make sure things are secure.  So what may seem like three distinct risks, is really just three aspects of Enterprise risk.

That, however, is not that most misleading thing in the preamble.

Consider the statement “increased complexity and connectivity of critical infrastructure systems.”  While we can all agree that the world of systems is getting more crowded, one could argue that mobile apps are simpler than many enterprise applications.  So to the extent that more and more is being done with mobile apps, maybe things are getting simpler.

And while the A.I. folk ponder when a machine will develop consciousness (machines as beings), the rest of us might be more immediately worried about when will absolutely every object in the world (living beings included) have an IP address (humans as endpoints).

Those IP addresses and the internet itself aside, most of us in security are as worried about the devices we are not connected to, i.e., the ones we do not control, as the increased connectivity of the world.

The statement that there is “increased complexity and connectivity of critical infrastructure systems” is not incorrect, but it is only correct when you take the narrow view of “critical infrastructure.”  Once you expand it to the on-line world that is evolving, a different picture emerges.

The world’s infrastructure is becoming more crowded with simple applications and while there is increasing general connectivity, the real aspect that is making the connectivity complex is not messaging and networks.  It is data.

Data is the knowledge a system has of the context it is running in.  It does not rely on direct connectivity (or, often, any at all) at a physical or network level.   In fact, even for connected devices, the more an attacker knows about the infrastructure (the more data they have) the more likely their attacks will succeed.

This is not a new idea, but it sometimes gets lost in all the focus on “connectivity.”  So, what follows will be a data-centric view of the Framework for Improving Critical Infrastructure Cybersecurity.  In doing so, I will try to show that while this document is not classified as one of NIST’s “Special Publications” (SP 800-x), it might be the most special of them all.

The post All Infrastructure and the NIST Framework appeared first on Security Current.

I tell users all the time “Forget everything you learned in Kindergarten.”  It always gets a laugh, gets their attention and gets my point across.

It’s not nice to share (your password).  Secrets are really ok (your IP address).  Not only should you not take candy from strangers, you should not take strange candy from people you know (probably a phishing attack).

You CAN mess with other kid’s stuff (if your workmate leaves sensitive information on the printer, it’s ok to lock it up).  And if you do nothing else, for heaven’s sake, don’t be helpful (why does the stranger on the phone need that information?) or polite. (Answering that email with a polite “no thank you” just confirms to the sender that they got a valid email address.)

Early childhood lessons are the social engineers greatest advantage.  Nonetheless, there is one childhood primer that I insist everyone who works for me reads (I provide them with a copy when they start reporting to me).

Crockett Johnson’s Harold and the Purple Crayon is required reading for all security professionals as far as I’m concerned.

This is not because Harold responds to every incident with creativity, although being creative is helpful in incident response.  It is not because he is never too rattled to focus on the task at hand except that one time his hand shakes, teaching us that reacting badly can get you in over your head.  It is not even because he knows how to use tools (the crayon, the boat) or enlist help (the moose and the porcupine).  These are important lessons to learn, but this book is not unique in teaching them.

The book is uniquely instructive because the problems and their solutions are of Harold’s own invention.  He creates the environment that facilitates his success and by so doing creates his vulnerabilities.  And that is something that security professionals tend to forget.  Unless you are employee number 3 of a start-up, the chances are the environment you must secure was created prior to your being charged with protecting it.  And the vulnerabilities are part and parcel of the environment.

The environment was created by individuals who had business reasons for doing it.  As you introduce new components to the environment, it will not always go as planned.  In other words, the vulnerabilities were introduced by you and others.  So remember, that responding to incidents may be a matter of dismantling or modifying something that someone considers their own.  Never forget to address the ownership of the systems you need to fix. To put it bluntly: lesson one is that everything belongs to somebody.

This evolving environment that Harold draws himself into, created as it is by a crayon, has one characteristic that is not like the environments we secure: Harold cannot erase anything.  This is the  second lesson I discuss with teams.

Assuming oyu have contained the problem, before jumping to the long term solution in incident response (just turn it off) consider how you would solve the problem if you couldn’t remove the component causing the vulnerability (which after all is sometimes the case).

This focuses you on improving your protective controls rather than just eliminating one more alert from your detective systems.  In fact, I find offering to leave vulnerable systems on the network by defining what mitigating controls would be required to make them safe is the surest way to get a system owner to think about shutting it down.

Finally, and most importantly, the third lesson is the moon.  It is what gets Harold where he needs to be in the end.  But it is as with everything else, Harold’s creation even though there is no evidence that he drew it as a means to find his way home.

I could get “new age” at this point and say the lesson is that the answer always comes from within.  But that’s really not the point here.  The point that is stressed throughout the book and driven home most by how Harold uses the moon is that once something is in the environment, it can be used for multiple things depending on your goals.  You may not realize its use right away.

Therefore, we learn most from Harold when we consider that he is not us.  Our organization is more focused and methodical.  It does not meander through a landscape it defines; we have architects and  build structures through engineering, budget approval processes and change control.

Harold is not us. He is, in fact, the perfect image of the opportunistic hacker: trying things, leaving them around and using them as he needs to.  He’s not a representation of every type of cybercriminal to be sure, but he is the kind that thinks and acts least like your organization.  What would Harold do?  That’s not the right question.  The right question is what exactly would work as his crayon and how can you take it away from him before he uses it.

The post What Would Harold Do? appeared first on Security Current.

In August of 2010, Huping Zhou who had served as a researcher at the UCLA School of Medicine and had since been terminated, was sentenced to jail time for inappropriately looking at the medical records of his immediate supervisor and some notable celebrities including Drew Barrymore, Arnold Schwarzenegger, Tom Hanks, and Leonardo DiCaprio.

He had violated the privacy of individuals not under his care; he had abused his legitimate access to the electronic medical record system; and he had  violated Federal privacy law.

Recently, the Bernie Sanders 2016 presidential campaign fired Josh Uretsky, their national data director.  The campaign has said that the immediate cause of the termination was his inappropriate access of data owned by the Hillary Clinton campaign.

The employee claims he was documenting a bug in the software program that allowed him access to the data in the first place to illustrate the extent of the bug.  The Clinton campaign claims he was exploiting a temporary flaw in the separation between the data of the two campaigns.

While at first glance, this can be described as another case of a worker abusing their legitimate access to records, the difference between Uretsky’s case and Zhou’s represents how the world of big data, massive collections of individual records that are used for precise analytics, has created a new paradigm in personal data.

The Democratic National Committee, through a third party vendor, maintains a comprehensive voter file and licenses use of it to campaigns for a fee.  Both the Clinton and Sanders campaigns subscribe to this service.

This information is so essential to modern day campaigns that when the DNC temporarily suspended the Sanders campaign’s access to the system, the campaign filed suit in Federal Court to have the access restored.

In the suit, the campaign points out as an example of the importance of the file that “In a fundraising drive conducted between December 14, 2015 and December 16, 2015, the Campaign raised more than $2,400,000.00 – or more than $800,000.00 per day. Most of this money came from individual donors identified through, inter alia, the strategic use of Voter Data.” (https://berniesanders.com/wp-content/uploads/2015/12/Bernie2016vDNCComplaint.pdf )

In the case of “celebrity snooping” of medical records, patient privacy is clearly breached.  But in the case of the campaign data, individual voter privacy was not necessarily accessed inappropriately.

According to the suit, by contract with the DNC, the campaigns have access to “demographic and geographic data for registered voters (such as name, address and jurisdiction); email addresses; voter registration status; telephone numbers; vote history; commercially acquired consumer data; ethnicity information; political party preference or affiliation, if any; candidate preference data, if any; and other key analytic metrics selected by the DNC.”

What was inappropriately accessed was the proprietary information that the Clinton campaign had, at their own expense, appended to the individual records.   These derived attributes account for the real value of the data to the campaign.

The value is in the analysis these attribute enable and that allow the campaign to plan and execute strategies.  The privacy expert Sara Degli Esposti describes this value as being contained in “actionable insights” which lead to “interventions.”  In her article “When big data meets dataveillance: The hidden side of analytics”, which appeared in the journal Surveillance & Society, she writes:

“the term ‘actionable insights’ indicates a form of discernment generated to produce an action, rather than a theoretical description or comprehension of a phenomenon. Accordingly, the term ‘intervention’ gives emphasis not only to the active role played by analysts in creating the new knowledge, but also to the potential for change embedded in the knowledge created.” (Degli Esposti, S. 2014. When big data meets dataveillance: The hidden side of analytics. Surveillance & Society 12(2): 209-225. http://www.surveillance-and-society.org | ISSN: 1477-7487)

When big data is analyzed, actions can be taken based on that analysis.  Hence, the Sanders campaign data analysts (three others aside from Uretsky appear to have accessed the data), if they were intentionally accessing the Clinton data to learn about the opposing campaign’s strategies or develop new ones of their own, were essentially doing what they were hired to do: run queries against the data and get actionable insights from it.

Perhaps the most famous actionable insight derived from data analysis was one of the first ones.  In London in 1854, John Snow mapped the data on the Cholera outbreak centered around Broad Street and determined precisely what corrupted water supply must be causing the disease.  Data analysts (now also known as “data scientists”) take great pride in the “aha” moments when their insights lead to breakthroughs.  And this desire to find that game changing insight in the data may cloud the analyst’s judgement.

Whatever his motivation, Uretsky’s accessing the data can be seen as an example that when it comes to data access, there is a difference between “can” and “should.”  Because individual level privacy was not compromised, this breach did not fall under any of the notification requirements that are law at both the Federal and State levels.  It came to light because of the very public reaction of the DNC, which suspended the Sanders campaign’s access to the entire system.

Increasingly, in the world of big data, there is data about you that you have a stake in.  For some types of data, your rights are spelled out in regulations such as Health Insurance Portability and Accountability Act (HIPAA) and Equal Credit Opportunity Act (ECOA) and then there is data about you that is not controlled.

These data attributes, derived from your personal data, group you into cohorts and allow the organizations that create and use it to take action on it.  While there are some cohorts you belong to that you are aware of (i.e., “female between the age of 30 and 34”), there are others you can only guess at.  I in this case “most likely to vote for Clinton” or “most likely to donate $100 or more.”

While it is a generally accepted principle of privacy among regulators that individuals should have the right to know what data is collected about them and be able to correct it, that right does not extend to the cohorts a data collector puts the individual in.

Being in the cohort that is the US no fly list perhaps is the best-known example of this.  If a public record search showed that someone with a name identical to yours had been arrested on suspicion of terrorism, you could challenge that that record shows up in searches about you.  But that would still not necessarily allow you to know that your name is on watch lists or get it removed from them.

When identity is abstracted from privacy, data is no longer in the control of the subjects of the data.   This is both a loophole in regulatory frameworks and a necessary protection to ensure the proper handling of large datasets.

The post The Sanders-Clinton Data Brouhaha: It is Not About Privacy and All About Identity appeared first on Security Current.