Another Research Idea Stolen
By Adam Dodge
Well, it has happened once again. Those folks over at the EDUCAUSE Center for Applied Research (ECAR) have stolen yet another of my research ideas straight from my head before I had a chance to move forward. As always is the case, the result of their mindreading theft is far beyond what I could have accomplished. This most recent case of cranial theft resulted in the ECAR occasional paper titled “The Career of the IT Security Officer in Higher Education”. I want to take a moment to issue a big thanks to Marilu Goodyear, Gail Salaway, Mark Nelson, Rodney Peterson and Shannon Portillo for taking the time and effort to author this amazing paper.
The paper itself is a collection of statistical information gathered from survey responses and follow-up interviews with individuals tasked with IT and Information Security within institutions of higher education. The paper looks at three main sets of issues around the IT Security Officer function at colleges and universities. These sets are: “The Position and the Person”, dealing with reporting lines, previous positions held and demographics; “Responsibilities, Skill Sets and Professional Development”, dealing with responsibilities, job announcement analysis and reaching out for advice; and “Authority, Challenges and Program Strategies”, dealing with authority within the institution, common challenges to authority, and security program strategies. While only 53 pages in length, there is too much information in the paper to fully cover here. Instead, I wanted to focus briefly on a few of the more interesting takeaways from each area.
The Position and the Person
One of the most interesting things I found in this section is that only 64.7% of IT Security/Information Security Officers (the two terms are used interchangeably in the paper) still report to CIOs within their organization. On its face this may not be interesting, but the next most common reporting line is the CTO, although granted, only 8.1% responded thusly. Given the inherent conflict that exists between operational IT (“We need this working and working now”) and IT security (“We need to take time to fully vet the system before production”), I find it odd that just under 1 in 10 (1 in 12.5 if you must) ISO/ITSOs still report to the individual responsible for technical operations. While this arrangement can work, it often does not as operational issues tend to take precedence over security concerns.
Another quick takeaway is that the typical ages of ITSOs/ISOs tend to be younger than I would have expected, with almost 19% of respondents ranging between 30 and 34 years old. Additionally, over half of the respondents reported to being in the ISO/ITSO role for three years or less.
Responsibilities, Skill Sets and Professional Development
Personally, I think that the largest potential shock for non-security professionals in the ECAR paper comes when looking at the average areas of responsibilities. Instead of being filled with a long list of highly technical areas, common responsibilities instead focus on management-level activities such as incident management, training/awareness, policy development/administration, risk assessment, regulatory compliance efforts, etc. In fact, when looking at technical security areas such as IAM, access controls, network security/firewall management, etc. the majority of respondents only listed that they had a “support” role. This is indeed an excellent development within the higher education field as it signals a much needed shift in thinking about IT/Information Security away from the “network security” box it has been in for far too long.
Other interesting takeaways include that despite what was said above, technical knowledge/expertise was listed as a critical need skill in 69.5% of the ITSO/ITO job positions wihtin higher education. Also, while only a minority of ISOs/ITSOs (41.8%) report having control over a dedicated security budget, these individuals cited this budget control as a key component in improving security at their institution.
Authority, Challenges and Program Strategies
Another positive trend shown in the ECAR paper is the fact that a vast majority of the respondents indicated that they have been vested with the authority necessary to perform their jobs. In fact, over 78% of the individuals surveyed responded they had the authority necessary to enforce policies and ensure policy compliance, monitor networks and systems, and authorize the removal of equipment and access rights if necessary. Hopefully, this marks the end of the dreaded cheerleader ITSO/ISO who has been given all the responsibilities for IT/Information Security but none of the requisite authority, and thus is doomed to wander the ivy halls of academia impotently shaking fingers at problems, and hoping against hope that this time the problem will be addressed.
A few more takeaways of note from this section include the fact that while faculty are the most common group on campus to challenge ISO/ITSO authority, such challenges only occur occasionally. Even better is that the single most common method deployed by ITSOs/ISOs when challenged is not pulling rank or blustering about, but is instead rational and reasonable discourse to explain the reasons behind the request.
Fortunately for everyone without an ECAR membership (myself included), this occasional paper has been released to the public. I urge everyone to take a short Internet trip to the ECAR site and give the full paper a read-through.
Letting the Horse Catch Up to the Cart
By Adam Dodge
I recently returned from yet another amazing time at the EDUCAUSE Security Professionals Conference. Out of all of the different security conferences that I have had the good fortune to attend, and out of all of the conferences that have taken pity and allowed me to talk, the SPC continues to be one of my favorite events. Not only does the SPC boast outstanding presentations, but the hallway conversations, informal roundtable discussions during meals, and Birds of a Feather gathers offer unparalleled opportunities to meet other security professionals in higher education and learn new, unique ways to address issues. I strongly urge all security professionals in higher education to beg, argue or barter for the funds needed to attend this yearly gathering.
The conference lineup this year was interesting. While there were the usual technically-focused talks, the majority of the talks did not center on specific technical topics. Instead, much of the conference was focused on building and maintaining a strategic information security program within higher education. There were sessions on building risk management programs, using frameworks to build information security policies and programs, creating standardized and measurable procedures, and even talks on how to leverage internal resources such as internal audits to help improve security posture.
Like many industries, information security grew up out of the IT departments at most colleges and universities. Unfortunately, many educational institutions still equate “network security” with “information security”, and information security is often still viewed as a technical issue. However, the presentations at this year’s conference clearly indicate that the viewpoint on information security is quickly changing at colleges and universities.
This shift in how information security is viewed within higher education speaks to the maturation of information security programs at many colleges and universities. Thankfully, the industry seems to be moving away from the misguided view that all institutions need is one staff member “doing security” to be secure. This type of growth and maturity of information security programs within higher education is a great sign that perhaps I will soon have nothing to report on Education Security Incidents.
Here, in no particular order, are the top three presentations out of the sessions I was able to attend. “An Auditor’s Perspective on Frameworks for Information System Security in Higher Education” by Erwin Carrow and Brian Markham were useful in teaching me that internal auditors can, in fact, be your friends. “Using the EnCase Field Intelligence Model in Assisting with Forensic Examinations” by Yu Chang, Tammy Clark, and William Monahan were useful in showing how Georgia State University handles requests for forensic investigation. “Mapping the Shifting Landscape” by Phillip Deneault and Brain Smith-Sweeney were useful in providing excellent quotes such as “Ready-Fire-Aim” and Brian’s poorly rendered yet still amazing image on the drivers and functions of an information security program.
Congratulations and thanks are in order for this year’s SCP program committee. These folks did an outstanding job.
Image used with permission from FreeDigitalPhotos.net
Open Request To Salespeople
by Adam Dodge
A few months ago, Andy IT Guy (here and here) and Alan Shimel (here and here) engaged in a blog-vs-blog debate on dealing with security product salespersons. Having just returned from a great time at Source Boston, I now find myself dealing with the ever present post-conference sales calls. Instead of rehashing the points that Andy and Alan brought up in their posts, I thought I would spend some time listing out a few requests to all sales people reading this post.
Request #1: Don’t approach our relationship as a sparring match
Let me start out by saying that I have no problem with salespeople and often welcome the information they provide. However, my time is not always my own at work. I have responsibilities that need to be attended to, meetings to attend and the occasional fire to put out. This means that there are days, and even weeks, when I am in and out of my office all day. If you call and receive my voicemail it is because I am busy, not because I am ducking your calls. Please feel free to leave a message or send me an email about your product. Whichever you choose, just make sure you do not keep calling over and over again without leaving a message. This type of behavior tends to sour my opinion of your company rather quickly.
Request #2: Respect what I tell you at a conference
Often at conferences I’ll see a company I am not familiar with or a product that looks interesting. Being a curious fellow, I often stop at these booths to find out more information. However, I am always upfront and honest as to whether or not I feel it would be a good fit in my environment or if there is a budget for this type of product. Please respect this and forward it to your sales staff. I understand that these conference booths exist to help generate sales leads and I respect that. When forwarding my information to your salespeople, do not tell them I am interested in your product unless this is what I have stated. My time is limited (see above) and I find it annoying to have the same conversations with salespeople over the phone as I did in person at the conference.
Request #3: Give me the data and let me decide
I understand the desire for salespeople and companies to highlight the major strengths of their products. After all, these strengths are exactly the reason I would want to purchase the product. However, if you are going to provide me with “proof” that your product is superior to the competition, I expect to be provided with the data behind these claims and the context for this data. If you do indeed have the better product, it should not be that hard to provide this information. Do not offer vague statements and unnamed sources and expect me to welcome your product with open arms. After all, if I am going to use my finite resources to purchase your product, I am going to do everything possible to ensure I get the best product possible for the money.
At the end of the day, I need security products to help monitor and manage my environment. I rely on salespeople to provide me with information on their products, get me in touch with individuals inside their companies to answer my questions and to keep me up-to-date on new products that might be of use. I understand that you are simply trying to do your job because that is all I am trying to do myself. There is no need for ours to be an adversarial relationship. However, if you choose to approach the relationship as such, I will happily take my business to a competitor if necessary.
Fail Better
By Adam Dodge
I have a not-so-secret secret to share with all of you today. I, Adam Dodge, tend to be a tad bit neurotic at times. Nothing very serious, mind you. I just have a tendency to obsess over the things I do. Afraid that I have somehow missed the glaringly obvious or that I have missed made a stupid mistake, I often read and research and then re-read and re-research. After this I start the process over again. My neurotic tendencies are never more obvious then when I am working on projects that will be shared with others.
For obvious reasons, I want my work product to be the highest quality possible, hence the obsession. I recognize the fact that, alas, I am not a perfect person and thus I will (and do) make mistakes. I jokingly refer to this as my “crushing lack of confidence brought on by being self aware.” However, whenever this happens something occurs to me.
It is okay for the work that I produce to contain imperfections at first. After all, if “security is a process and not a product”, then it is this ongoing refinement that allows you to overcome these imperfections. I feel the need to constantly remind myself of this fact, and it is one that I think it is important for us all to remember. Allow me to elaborate by explaining a project on which I am currently working.
I am working on creating training materials so that I can deliver annual training mandated by a regulation. Since this will be the first such training, I am faced with the task of creating most of the training from scratch. About halfway through developing the training, a thoughy struck me. This is some of the worst training material I have ever created!
It is not that there is a problem with the content. It is just that I cannot think of a way to present this information in an interesting or fun way. I am making several mistakes with this presentation: I am reading from slides. I have very little interaction with the audience. I have too many slides with too much information.
I am going to stand in front of a group of people and flash Powerpoint slides at them for 30 minutes. All the while I will be met with a room full of dead eyes staring at the clock waiting for me to be done. Okay, perhaps it will not be quite this bad, but you get the idea.
I have obsessed over this, agonized over how bad it will be until I remembered one little thing. It does not matter. This training will be held annually and it doesn’t have to be perfect out of the gate. I can gradually refine the material over time to address problems that I find, add additional material, and work to make things more interesting. Just because this training starts out bad, doesn’t mean that I have to allow it to continue to be bad in the future.
None of us should allow ourselves to become overwhelmed by the ideals of perfection. Nothing is perfect. Everything changes. Problems only become problems when we fail to do something about them. In the words of Samuel Beckett:
“Ever tried? Ever failed? No matter. Try again. Fail again. Fail better.”
P.S. If you are going to be at Source Boston, come see me and Dr. Kees Leune give a talk about Information Security in Higher Education!
Is This Helpful?
By Adam Dodge
On January 12, 2009, MITRE and SANS announced the release of the CWE/SANS Top 25 Most Dangerous Programming Errors list. Since the release of this list, there is been a lot of talk over whether or not this latest “Top XX” security list is useful. However, that is not the focus of this article. Instead, let’s take a look at the action of Will Pelgrin and CSCIC.
Announced at the same time as the list, CSCIC released “draft language” to help guide New York State procurement guidelines* to include provision for secure code. On the surface, this type of requirement is to be applauded. After all the goal is to require the development of secure coding and testing practices for all applications purchased by New York State agencies. However, this current draft still leaves several questions in my mind.
One of the first problems that comes to mind is that there is no mention of the increased costs associated with the tenets of the procurement guidelines. It goes without saying that the new requirements have the very real possibility of adding significant increases to both develop times and development costs. After all, activities such as mandatory background checks for developers, development vulnerability and risk assessments, and security control compliance customized per customer demand all have associated costs.
Should organizations eschew these secure coding practices in favor of faster products at a lower cost? Of course not, but this draft guideline should not ignore the fact that there will be an increase due to the requirements suggested. Interestingly enough, the OWASP Secure Software Contract Annex, off which the Application Security Procurement Language document is based heavily, does address this problem. In fact, OWASP encourages that such costs be negotiated as part of the procurement process, not ignored altogether.
Beyond actual coding practices, one requirement that the proposed procurement guideline calls for is increased documentation. Generally, more documentation is a great idea and the documentation called for in the procurement guideline (in most part thanks to the work by OWASP) will allow organizations to fully understand not only the security controls used during the software development process but also the proper security configurations to employ. However, none of these increased documentation mandates require that the purchasing organization actually understand all of this increased documentation.
Of course, such language would not be appropriate in a procurement guideline, but the simple fact is that no amount of documentation will help ensure secure operation of any software application if the individuals running the application do not understand what the documentation specifies. Organizations need to ensure that there are staff resources available internally to interpret the documentation provided by developers in order to properly ensure the controls included in the documentation meet organizational requirements.
The final section of the procurement guideline is probably one of the biggest problems with the document. The intent behind the language used in the Investigating Security Issues is clear. After all, if a security incident were to occur due to a problem with the software, then the vendor’s help with investigating the incident would be immeasurable. However, the wording used in the actual guideline simply ensures that very few - if any - procurement contracts will contain this incident investigation support requirement.
The problem is that the procurement guideline takes its intent from one of the OWASP stipulations, but ignores the importance of the supporting sections of the OWASP Annex. In short, OWASP calls for Developer support during incident investigations but allows for the fact that the incident may involve a wholly unique issue outside of either security requirements or “reasonable” security testing procedures. After all, complete security today does not ensure complete security tomorrow. Any secure coding requirement needs to allow for the fact that there will be unforeseen security incidents no matter how good the security requirements are and to allow for a good faith negotiation between developer and customer in such cases.
*Please note the links to the procurement guideline point to the online SANS mirror and not the PDF document on the CSCIC web site. This was done because the CSCIC PDF does not reference the OWASP Annex.
Editor: Join additional conversation on this topic in the Security Catalyst Community: New York drafts language demanding secure code
The Breach-Stamp Metric
By Adam Dodge
One of the most difficult tasks any information security practitioner faces is clearly communicating the need for information protect in terms of dollars lost. There are many obstacles that one must overcome depending on the culture of their organization, including false sense of security, truthiness, and false proof. The problem, however, is that many organizations are unwilling to increase budgets unless there is a clear reason to do so. Therefore, many security professionals are in a position where they have a need for increased budgets (or perhaps even obtaining an initial budget) and yet are at a loss for how to communicate this need in a manner the organization can understand.
Of all of the different methods available, none are more controversial then ROSI or Return on Security Investment. There has been much talk about the good/bad/ugly of ROSI already, so there is no need to go into it here. If interested in this topic, any search will return a wealth of resources.
Personally, I tend to avoid ROSI in all but a select few circumstances. The problem with ROSI calculations are that often there is not enough information available to accurately calculate the actual return expected. This problem could be overcome in time since more and more information on incident costs are being calculated, but that is a while off.
I do like to use ROSI when dealing with any security control that allows for automation and the saving of FTE work hours. This type of calculation can go a long way when dealing with management since it shows a direct reduction of cost to the organization based on a specific purchase. However, one standard note of caution. When using ROSI to compute FTE hours saved, one thing that must be avoided is inflating and/or exaggerating the current FTE hours being spent on the task. Nothing will ruin an ROSI argument faster then unrealistic cost figures.
In fact, cost figures do not have to be necessarily false to be unrealistic… at least in the eyes of management. Unless an organization has experienced a major monetary loss due to a security incident, talking to management about the fact that each record lost will cost almost $200 to the organization can quickly become unrealistic when dealing with tens of thousands of records. This is a clear case where perception bests reality.
One of my favorite ways to combat the perception vs. reality problem when explaining the costs associated with security problems is to use easy to understand concepts and ideas. (This is an idea that I stole… I mean borrowed from Michael Santarcangelo) The approach I’ve had the best luck with is one I borrowed from Matthew Dalton of Ohio University that I’ve nicknamed the Breach-Stamp metric. The setup to this is easy, simply look at the costs to the organization, department, group, etc. for postage if the group were to suffer a breach.
The beauty of the this approach is that it takes something that everyone is familiar with, postage stamps, and shows how even modest breaches can have dramatic financial impact. For example, at $0.41 per stamp, a breach involving 15,000 records equals almost $5,000 in postage stamps for notification letters alone. One great question to ask after explaining this is if the organization, group, department, etc has an extra $5,000 available for postage costs. The added bonus of using something so insignificant as postage is that many individuals view postage as a minor inconvenience and large postage costs can come as a shock that might just help get the point across.
The fact remains that no matter what happens, communicating the cost of not protecting information in dollars lost will likely remain very difficult for most security professionals. However, since such arguments are likely to be the best, if not only, way to obtain necessary budgets, we all must learn how to communicate such costs in a manner that management can understand.
Breaches Cost Companies Customers
By Adam Dodge
There has been a lot of discussion around the value of breach statistics and breach reporting. Personally, I feel that organizations can find a lot of value by monitoring reported breaches. By studying what breaches are being reported, especially within the same industry vertical. Organizations can get a feel for how common breaches are among like institutions. Leadership can gain insight into if the organization’s current security controls will help protect against commonly occurring breach patterns and discover areas of their current security programs that need improvement. Organizations can even gain a better understanding of what steps are taken by fellow institutions in response to the breach, since these common response will most likely be expected by customers should the organization itself suffer a breach.
However, the one area that breach reporting and most breach statistics fail to cover is what happens to the business after a breach. Questions remain surrounding the long term impact of data breaches on organizations in terms of increased regulatory oversight, loss of consumer confidence and difficulty attracting new business. After all, nothing makes the case for increased security quite as strongly as reductions in the bottom line and increased red tape.
Fortunately, two recent studies help shed some light on what exactly happens to consumer confidence in an organization after a data breach. In April, ID Experts and the Ponemon Institute released a study that looked at consumer response to data breach notices. (Please note for this post I am respecting the disclaimer of this study and will only use information available in the press release.) Two months later, Debix and Javelin Strategy & Research released the results of a consumer survey surrounding data breach notifications in June.
The topics and titles are not the only similarities between these two studies. Even though the methodologies cited in the studies were completely different (Pomemon used responses from a survey of 1,795 adult-aged respondents throughout the US while Javelin used an online survey of 400 data breach victims as well as in-depth interviews with two breached institutions) the numbers reported by both are shockingly similar. In fact, they are so similar that even as I write this I have this nagging feeling that somehow these might be the same report.
The results of the two reports (one report?!?) show that 55% (Javelin)/57% (Ponemon) of the individuals lost trust in the organization. Even worse, 30% (Javelin)/31% (Ponemon) of individuals notified of a breach terminate their relationship with that organization. Think about that for a second. Roughly 1 out of 2 customers will lose trust in an organization while 1 out of 3 will discontinue business with the organization following a data breach.
What do these numbers mean to us? Well, if you are in an organization that relies on continued customer revenue, these number mean a lot.
These numbers are a great starting point for computing the impact of breaches beyond clean-up and notification costs. Ignoring any security ROI proof of impossibility magic, the simple fact that 1 out of 3 individuals ends their relationship following a breach is something needs to be communicated to business leadership. These reports were not some academic exercise of what may happen. The reports looked at what real people did following breach notifications. Real people leaving real businesses can be a powerful selling point for professionals stressing the importance of security in their organizations.
If an organization does suffer a breach, this information is ideal to for helping leadership understand what is coming in the long run. Instead of simply running off guess work, gut feelings and “truthiness”, the organization can plan for an average reduction in repeat sales and use this information to develop compensating controls on how to cope with the loss. While the likelihood of suffering a loss of exactly 30% is low, it is a starting point to help business weather the post-breach storm.
With consumers quickly becoming aware of the importance of security, organizations have started using security as a selling point. Don’t believe me? Take a look at the Bank of America, Wells Faro and Citibank web sites. See those little locks signifying “secure” access to accounts? Why would these companies bother with this unless there was no benefit?
The general public is starting to gain an awareness of security in a way that did not exist a few years ago.* What this means is that if organizations start to become secure (real security not security theater), this selling point could be used to draw in those 30% of customers that leave competing organizations following a breach. How’s that for security enabling business?
*This excellent point was actually thought up by David Mortman over a recent dinner with Andy Willingham, Adrian Lane and myself.
If you haven’t already, I strongly urge to all of you to go read the full ID Experts/Ponemon and Debix/Javelin reports. Each report is full of great information that I didn’t touch on here such as do customers find breach notifications helpful, what do customers expect in terms of fraud protection and how soon do customers expect to be notified following a breach.
Vacuums and Security
By Adam Dodge
This weekend I finally did it. I was tired of the sub-par performance. Tired of being forced to redo the same job over and over again to get it right. Just plain tired of nothing working like it should. So I broke down. I had just had enough. This weekend I bought myself a new vacuum.
That’s right, yours truly is the proud owner of a fancy new vacuum cleaner and, believe me, it was well worth the purchase price. The amount of – let’s call it crud – crud that I pulled off my floor was downright sickening. Yet, it was also amazing. Here I thought that I was actually cleaning when vacuuming and all I was doing was tricking myself. Yes indeed, the vacuum was an excellent purchase. As an added bonus, I now have all these new attachments with which to play.
So what does all of this have to do with information security? Plenty. Anyone working in the information security field knows the pain of trying to institute necessary changes and running into the all to frequent wall called “I’ve been doing it this way for X years”. (This wall is also know as “Other organizations are doing it this way”.) Like me with my broken vacuum, people are comfortable with familiarity and often resist changing until absolutely necessary.
One of the tenets that gets tossed around when implementing any type of security controls is to make the process as transparent as possible to the target audience. Generally, we take this to mean that the controls should be hidden away from the end user as much as possible. However, there is a better way. Whenever possible, we need to improve security by implementing solutions that offer minimal differences in all aspects. In other words, replace the broken vacuum with a new one, not a mop.
However, simply because I replaced my old, broken vacuum with a shiny new one does not mean that I will be happy with the purchase. After all, if my new vacuum required complicated setup or extra operating steps (for example, constantly having to change a bag) I would by annoyed. Luckily this was not the case, two screws and an on-off switch equals a happy Adam. The same is true for any new security controls. Replacing a control with a better, yet familiar, control will only lead to frustration and avoidance of the new control.
Of course, new additions are not always a bad thing. For example, my vacuum came with a few attachments that I did not have before. Some of these attachments, like the upholstery cleaner, are welcome additions. (Long, white haired cat plus upholstery equals a chore!) However, other attachments, such as the “electro-static duster”, are not so useful.
The best part is that these additional components do not affect the main operation of the vacuum. The same should hold true for any security improvements we try to implement. Optional services need to be just that, optional. While these geegaws may add value, the main focus of the control needs to be the basic functionality of the control.
So there it is. Frustration with a bad vacuum cleaner leads to thoughts on how the best approach replacing outdate/non-functioning security controls. My mind works in mysterious ways. What are you still doing here? Go out and start selling vacuums at your organization.
On Reports (a perspective)…
By Adam Dodge
Lately, there has been a flurry of activity in the land of security breach reports with organizations such as Debix, Verizon, the Identity Theft Resource Center and the Department of Justice all releasing reports looking at security breaches, breach notification laws and the state of information security in general. As someone who has been in the world of tracking and monitoring breaches for two years now through Educational Security Incidents, I am excited over the increased attention and information that is coming forth and the lessons that can be learned from these breaches. However, it is important to remember that are inherent limitations on the applicability of breach statistics and therefore we all must be cautious about reading too deeply and arriving at conclusions that the information in these reports do not support.
Before we go any further, yes I do develop a similar report each year and yes my report is subject to the same limitations as all of these other reports. My point here is not that all other reports are wrong while the ESI YiR is the shining beacon of truth. The point is that the information delivered in these reports is simply that, information. It is up to the reader to interpret this information in a meaningful way. The problem, then, stems from misinterpretation and this
What do I mean by “misinterpretation”? Well a common problem with the statistics provided in these reports (remember, I’m including my own report as well) is that the numbers are based the sample set and the ability to apply these numbers depends a great deal upon the size of the sample and how randomly the sample was chosen from the total population. Alright, that might not be a good enough answer so allow me to explain further.
The Verizon report has made a big splash in the security world and for good reason. Verizon did an amazing job with this report. If you haven’t read it, go do so now. Seriously, stop reading this and go read the report. It is that good.
However, the report is based around 500 forensic investigations performed by Verzion’s Business RISK team between 2004 and 2007. These 500+ breaches that Verizon has analyzed for this report were not randomly chosen from all breaches that occurred. Instead, the information was mined from the investigations stemming from breaches that were serious enough for a company to reach out and contract with Verizon for assistance. This is a potential point of bias for this survey.
Most companies are not going spend money on investigations for small breaches or those that are easily explainable. Therefore, it is very likely that breaches of data such as information left in public, information accidently placed on a public web site, etc. are underrepresented in the sample Verizon used. It is also likely that smaller companies and non-profit organizations are underrepresented as well since these entities lack the funding that larger, for-profit organizations have at their disposal.
What does this sample bias mean for the validity of the Verizon report? Nothing. Nothing at all. There is no problem with the sample bias of the Verizon report. The simple fact is that all of security breach reports (again, including the ESI YiR) suffer from the same problem. Unfortunately, there is no go way around this problem yet. Everyone that I talk to involved with tracking breaches has the same complaint: There is no centralized reporting of breaches in the United States and those states that do require breach reporting to a central authority have different reporting requirements, litmus tests and public access to breach information.
So I am suggesting that everyone stop reading these reports? Absolutely not. It is not just self-preservation that makes me say this, however much I enjoy my work with ESI. These reports are an excellent way for information security practitioners to track the movement of threats and discover what types of security threats similar organizations are facing. The point of all of these is that each and every one of us (including the media) need to make sure that we are interpreting the data of these reports properly before we remove our firewall because the 2007 ESI YiR said that employee mistakes outnumber hackers as the cause of a breach 2:1 or before we discontinue our security awareness and training programs because the Verizon reports says that 73% of all breaches came from external sources.
How can these reports be so different and yet both be correct? Simple, look to the samples used to compile them.
Breach vs. Incident: Semantics or Something More?
By
Recently, the
In an article over at The Monitor, UTPA Vice President for Business Affairs, James Langabeer stressed that the loss of this external hard drive was only an “incident” and did not constitute a “breach” by an outside individual. According to Langabeer, “It is an incident, it’s not a breech. A breach is when someone takes something out of your computer and deliberately takes it from you. If you lose it, it’s an incident”
What I find so fascinating about this statement is that the distinction between incident and breach and that an “incident” should not be viewed in the same light as a “breach”. So I started thinking, is this distinction merely a semantic issue or are there some underlying assumption amongst the general public that an incident is an everyday, and perhaps less dangerous, occurrence then a breach. One of the words is a simple noun that brings to mind a singular event of some type that may or may not be harmful. The other word is more action oriented and brings to mind, at least to my mind, images of whales bursting through the surface of the water and other dynamic events. Given the very differences in these words, should they be used as interchangeably as they are in the Information Security arena?
I think that making a distinction between breach and incident in this manner is dangerous. While I believe there are indeed differences between breach and incident, I do not agree with the portrayal of each being separate from the other. Instead, a breach is a subset of the overall types of information security incidents that can affect an organization. Other types of incidents can include theft, loss, unauthorized disclosure, denial of service, mistakes, and a whole host of other issues that are too numerous to list. In the end, any occurrence that is contrary to current information security controls is, in effect, and incident. This means that any breach of information systems, past security controls, is in fact an incident.
One thing that we absolutely need to make clear as security individuals is that these “incidents” caused by internal employees are, at the very least, just as dangerous as “breaches” by external attackers. I have written a few times about the insider threat faced by organizations. Studies have continued to prove that internal employees cause a large majority of information security incidents. Yet, organizations still attempt to pass off employee misconduct as a lesser offense when in fact these are the very employees who both know where the information is and have direct access to this information.
However, in the end, whether caused by a “breach” or an “incident”, the loss and/or exposure of protected information is a signal to the organization that something is not working properly. This is what is important. We need to understand that it is not just about fixing the problem. Instead, it is about understanding why the problem occurred and creating controls to help prevent like occurrences in the future.
Unfortunately, it seems that more organizations are beginning to make this distinction in press releases surrounding security incidents.
Engage with Michael
-
Journey Into the Breach
