Posts

Showing posts from August, 2012

SMotW #21: unclassified assets

Security Metric of the Week #21: proportion of information assets not marked with the correct classification There are three key assumptions underlying this week's Security Metric of the Week: The meaning of "information asset" is clear to all involved;   There are suitable policies and procedures in place concerning how to risk-assess and classify information assets correctly; The metricator (person gathering/analyzing the data for the metric) is able to tell whether or not a given information asset is (a) correctly classified and (b) correctly marked. Part of the concern about the meaning of "information asset" is the determination of what should be assessed and marked: should we classify the filing cabinet, the drawers, the files, the documents or the individual pages?  In some cases, it may be appropriate to classify them all, but there are practical limits in both the micro and macro directions.  The wording of the policies, procedures, examples etc. can ma...

The ultimate question

Image
In the field of security metrics, much has been written about measuring all manner of detailed parameters that are deemed relevant and important, but the kinds of big-picture strategic questions that matter most to senior management are seldom addressed.   Take for example the disarming, devilishly simplistic question " Are we more or less secure than we were a year ago? "   Imagine being asked precisely that question by, say, the CEO or the minister.  How would you actually respond?  What if it turned out the question was not merely an off-the-cuff comment but a deadly serious request for information posed on behalf of a management team struggling to make sense of next year's infosec budget requests in relation to all the other proposals on the top table?   Go ahead, picture yourself squirming in the hot seat.  What's going through your mind?  Where do you even start to address such a naive question? For some of us, our knee-jerk reaction is to s...

IASAP International Association of Security Awareness Professionals

The CSI Security Awareness Peer Group has reformed itself as a non-profit organization after CSI discontinued the group last year.  IASAP (the International Association of Security Awareness Professionals) offers a supportive forum in which security awareness professionals can meet up and share good ideas.   A former CSI manager remains involved in the role of coordinator and meeting facilitator. IASAP membership is limited to those who are running security awareness programs within their companies: vendors of security awareness, training and related products are supposedly excluded although, paradoxically, PhishMe Inc. is the group's "exclusive founding sponsor" and "corporate sponsorships" are acknowledged as a source of funding on the IASAP website .   Perhaps as a consequence of the no-vendor policy, annual membership costs $2,500.  Members presumably anticipate recovering at least as much value through networking and sharing ideas and materials with their p...

Breaking Sod's Law

A news piece about a failure of the 911 emergency phone services during a storm is valuable security awareness lesson for any organization that relies on a generator-backed UPS to maintain clean, stable power to essential ICT services - meaning practically every large organization and many smaller ones too. Reading somewhat between the lines, the Fairfax County 911 ICT services depended on a UPS, the batteries in which were supposed to be kept fully charged by two generators in case the mains power failed.  One of the generators worked fine but the other evidently failed to auto-start.  Insufficient capacity in the one running generator meant that the UPS batteries gradually ran down over a few hours until eventually the UPS ran out of juice, the lights went out and the 911 ICT services failed. Moments after the initial power cut, the technician/s on site were probably relieved that the change-over from mains input to generator input had gone smoothly, and the ICT services ca...

SMotW #20: uptime

Security Metric of the Week #20: ICT service availability ("uptime") Uptime is a classic ICT metric that is also an information security metric, although it is seldom considered as such. Uptime is commonly measured and reported in the context of Service Level Agreements or contracts for ICT services, but in our experience this is usually something of a farce.  The IT Department or company generally defines uptime narrowly in ways that suit their purposes rather than being a true reflection of the ICT services actually provided to the business users/customers, while business people don't honestly believe the numbers anyway since (a) they do not reflect their experience as consumers of ICT services, and (b) they are self-assessed and self-reported by the IT people  who clearly have an interest in reporting only good news.  Tying internal ICT cost recovery to uptime  makes things even worse from the security metrics perspective ( i.e. providing genuine, fact-based data...

SMotW #19: employee turnover/absenteeism

Security Metric of the Week #19: rate of change in employee turnover and/or absenteeism In most organizations, employee turnover rumbles along at a 'normal' rate most of the time, due to the routine churn of people joining and leaving the organization.  Likewise, there is a 'normal' rate of absenteeism, due to sickness, holidays/leave and unexplained absences.  Big changes (especially sudden increases) in either set of numbers suggest the possibility that information security risks associated with disaffected or malicious employees might6 have substantially increased, in other words increased turnover and absenteeism may be indicators of a discontented workforce voting with their feet, or indeed of management sacking loads of employees. Of course there are many reasons why people leave the organization or are temporarily absent, aside from discontent and redundancy, hence the metric is unlikely to be particularly useful in isolation.  We refer to it as an indicator, si...

Social media naivete

Users of social media sites such as Twitter and Facebook don't always appreciate how much information they are giving away as they naively post updates.  For example, this site  figures out where you live  from the GPS info you send to Twitter from your Android system, looking up the latitude and longitude on Google Street View, while this site simply filters Facebook updates for potentially incriminating or embarrassing information. Using social media Application Programming Interfaces to query their public message databases is much the same in principle as using Google to find sensitive stuff published inadvertently on the Web.  Once information is published, it is there for people to use.

Awareness lessons from Wal Mart

This year's social engineering 'capture the flag' competition at the DefCon hackers' conference was won by a contestant who socially engineers his clients' employees for a living.  In the course of a 20 minute phone call, he successfully fooled an unsuspecting Wal Mart employee into revealing potentially sensitive and valuable information, even persuading him to visit a (potentially infectious) website to 'complete a survey'.   Read more about the con here . The con was cool in the sense that, live on stage, the contestant collected all the flags on his task list, but uncool in the sense that the attack was relatively straightforward and entirely benign, within the strict rules of the competition.  I've read about many similar attacks in books such as  The Art of Deception ,  The Art of Intrusion  and  Ghost in the Wires  by Kevin Mitnick, and  Spies Among Us  by Ira Winkler.  In  No Tech Hacking , Johnny Long writes at le...

SMotW #18: security spend

Security Metric of the Week #18: information security expenditure At first glance, this metric looks like it would be ideal for those managers who are obsessed with costs.  "Just how much are we spending on security?" they ask, followed shortly no doubt by "Do we really need to spend that much?" OK, let's go with the flow and try to get them the figures they crave. Our first challenge is to define what counts as security spend, or more precisely information security expenditure.   It's pretty obvious that the salaries for full-time dedicated information security professionals go in that particular bucket, but what about the security guards, or the network analysts and systems managers, or the architects and programmers spending some variable proportion of their time developing security functions?  Oh and don't forget managers and staff 'wasting their valuable time' constantly logging back in or changing their passwords or whatever: does that c...