Intranet stats - a neglected security metric

Most organizations of any size have a corporate intranet and I suspect you, dear reader, have an information or IT security website on yours.

Are you tracking the page views?

The count, or rather the trend in the number of page views for the security site can be an interesting, useful, perhaps even PRAGMATIC metric in its own right.

Take this very blog for example. Google kindly tracks and conveniently provides the admins with page view statistics in the form of little blue graphs. Google's default stats view shows the daily page counts for the present month, something like this:

Given the specialist nature of security metrics and our relatively narrow (distinguished, enlightened and very welcome!) readership, the default graph is too peaky, whereas it is a little easier to identify trends from the monthly version:

Pulling further back, the aggregated annual stats follow a pretty clear pattern which we've picked out by eye in red just in case you missed it:

The book had not even been printed when we launched this blog back in 2012. Interest peaked when it was published in January 2013, then declined gently until a few months ago when we are delighted to report that the upward trend resumed quite strongly - a second wave maybe.

Of course in spotting the second wave we might be exhibiting 'confirmation bias', one of many biases noted in the book, and if it mattered we really ought to consult a qualified statistician to analyze the numbers scientifically rather than 'by eye' ... but this is merely an illustration, and 'by eye' is good enough for our purposes. We're plenty patient enough to wait the months it will take to determine whether the apparent upward trend turns out to be genuine or just wishful thinking!

Turning now to your intranet security site, page counts like these are just one of a wide variety of statistics that the intranet webserver almost certainly tracks for you. Most webservers record far more information in their logs, while if you choose to go that route, dedicated tracking and analytical applications (such as Google Analytics for publicly-accessible sites at least) offer a bewildering array of statistics concerning things such as the pages visited, time spent on each page, website assets downloaded, the sequence of pages visited, browser versions, visitor locations and more. True, some of those details can be witheld or faked by the more security-conscious or paranoid visitors, but that's even less likely on an intranet than on the WWW so can be safely ignored in this context.

The big question, as always, is "Which metrics are actually worth the effort?" It costs real money to gather, anlyze, present and consider metrics, so as with any other business activity, they need to earn their keep. Figuring out the answer, as always, involves first understanding the organization's goals or objectives for the intranet site, then elaborating on the questions arising, then identifying potential metrics, and finally down-selecting a few cost-effective metrics using an approach such as PRAGMATIC.

It can be quite interesting and useful to elaborate on the objectives for an intranet site, although we seldom bother, while the questions arising are equally revealing.  One might well ask, for example:

• What constitutes a successful security intranet site?  How do we define success?  What are we trying to achieve?
• What proportion of employees visit the site over the course of, say, a year?
• Which parts of the site are the most or least popular ... and why?
• Which pages are the most or least "sticky" or engaging ... and why? 
• How does information security's intranet site stack up against other business departments?
• Do visits to the site reflect awareness and training initiatives, or incidents, or something else (can we explain the patterns or trends)?
• Are certain groups or categories of employee more or less likely than others to browse the site? 
• ... 

... Once you start, it's not hard to come up with a list of objectives, a set of questions and (implicitly at least) a suite of possible metrics. If you find yourself short of inspiration, this is an ideal task for a metrics workshop where participants feed and feed off each other.

Analyzing the possible metrics to identify those you intend to use can also be done in the workshop setting, pragmatically on scratchpads, or more formally using spreadsheets and documents that get circulated for comment. 

Of course, if all of that is too hard, you can probably get what you need, for now, from the page counts ... so track them, and don't forget to check and ponder the stats every so often. It's as a good place to start as any.

Happy new year!

Gary

Password awareness

We desperately need to get better at authenticating people if we are ever going to beat the scourge of identity theft and reverse the dreadful downward spiral that is already accruing costs in the tens of $billions annually.  

As a profession, we have a pretty good idea about what needs to be done, with multi-factor authentication and biometrics being high on  the list ... and yet by far the majority of IT systems still depend entirely on passwords. In other words, for the foreseeable future we're stuck with 'em and hence the security issues arising.

"Usernames and passwords are basically broken

from a security and a usability standpoint"

Jeremy Grant

Passwords are a particularly important topic for security awareness programs since so much revolves around the way we choose and protect our passwords. Furthermore, it's essential that managers and professional specialists appreciate just how broken passwords are as a security mechanism, if we are ever going to climb our way out of the pit of despair. Lack of awareness at their levels condemns us to an ever-worsening litany of privacy, security and compliance breaches.

Once again, we've come up with a fascinating variety of perspectives to explore on what would otherwise be a fairly humdrum information security topic. Security awareness is a vital control in relation to passwords since uneducated people are far less likely to realize the importance of choosing strong passwords and keeping them secret. We are encouraging employees to find more creative passwords, or rather pass-phrases that are both longer and more complex than the norm. For managers and professionals, January's awareness module goes into more depth on the strategic and technical aspects, respectively. It discusses multifactor authentication using security tokens or biometrics, for instance, and outlines the state-of-the-art in password cracking. 

As we plummet headlong into another new year, think of us if you find yourself idly dreaming about a security awareness program that never quite seems to materialize. Equally we'd love to support you if your awareness program is up and running. We know how hard it is to keep coming up with fresh ideas and creative content. Let me know if "Do security awareness" features on your long list of new year's resolutions ...

Management awareness paper on email security metrics

Measuring the information security aspects of email and indeed other forms of person-to-person messaging implies first of all that you understand what your security arrangements are intended to achieve.  What does it mean to "secure email"?  If that's too hard to answer, turn it on its head: what might be the consequences of failing adequately to secure email? Does that help?

Our next metrics discussion paper opens with a brief analysis of the 'requirements and targets', also known as the objectives, of email security, expressed in broad terms. For instance, preventing or at least reducing the issues relating to or arising from spam and malware is a common objective ... hence one might want to measure spam and email-borne malware, among other aspects. 

That in turn begs questions about which specific parameters to measure and how - for instance, there are many possible ways to measure spam, such as the:

• Number of spam emails arriving at the organization, or rather the rate of arrival (spams per hour, day, month or whatever);
• Number of spam emails leaving the organization (!);
• Types of spams detected, perhaps analyzed according to the differing threats they represent, ranging perhaps from trivial/timewasting to targeted spear-phishing attacks;
• Proportion of spam that is detected and blocked versus that passed to users (and, hopefully, identified by them as spam);
• Cost of anti-spam controls, including the anti-spam software and systems, network and system load, user and support time spent on the problem etc.

For each of those potentially interesting concerns, there may be several actual ways to generate the corresponding measures, and several ways to analyze, present and hopefully use the data. The paper outlines just a few examples to illustrate the approach, but it should be obvious from the above that we could easily have written a very long and boring treatise just on email security metrics. We didn't ... because the paper was 'just' written for awareness purposes: it is designed to get managers thinking and talking about security metrics, opening their eyes to the possibilities and encouraging them to consider their own, specific information needs as opposed to the few generic examples given. Rather than boring the pants off our readers, we're hoping to intrigue and stimulate them, catch their imagination not write a book on it.  [By the way, that's one of the objectives for the security awareness program, implying that perhaps we might measure it in order to confirm whether the awareness program is achieving the objective, and if not suggest how we might do better!]

In case you missed it, there's an important point here with implications for all metrics (not just infosec metrics!). What we choose to measure depends on our information needs, organizational circumstances, objectives, challenges, maturity level and so on.  Your situation is different, hence you will probably be better served by a different set of metrics. Much as we would like to offer you a little pre-canned set of email security metrics, chances are they won't work terribly well for you. They'll be sub-optimal, perhaps costly, distracting and generally unhelpful. Remember this when anyone enthuses about particular security metrics, or when someone naively posses the classic "What metrics are best for X?"

One might argue that since we share a number of common information security challenges (such as spam), we might benefit from a number of common metrics ... but that's overly simplistic, just as it would be nuts to suggest that we should all employ identical anti-spam controls. Some email security metrics might well turn out to be more or less common than others but that alone is not a sensible reason to select or avoid them respectively.

This is why we invented the PRAGMATIC approach. While it is easy to come up with long lists of possible metrics using methods such as Goal-Question-Metric (see Lance Hayden's book "IT Security Metrics") and metrics catalogs (e.g. the 'consensus security metrics' from CIS), there was a distinct lack of guidance on how to shortlist and finally choose the few metrics actually worth implementing.

NZ government agencies require security awareness

The New Zealand government published the PSR Protective Security Requirements this week, a well-written, readable policy manual. 

Publishing the manual in an online format through a content management system is commendable, not least because it is so easy to browse, search and (presumably) maintain. The custom views for 4 primary audiences (senior managers, security practitioners, employees and service providers) addressing common questions etc. are cool. The site structure/navigation, formatting/presentation and writing style are clear. More diagrams and figures would have been welcome to supplement the somewhat tedious monochrome text but I have certainly seen worse! Overall, it's a nice bit of web design.

Personally, I would have preferred the PSR to have explicitly adopted the structure of ISO/IEC 27001 and 27002.  Although one might argue that the ISO27k structure is arbitrary, it is at least reasonably logical and familiar around the world, making it easier to compare and contrast the NZ approach with globally-accepted good information security practices.  NZ may be special but it is hardly unique! Unfortunately, NZ Government pays scant regard to ISO27k, in contrast to our colleagues across the ditch in Australia. An opportunity squandered.

Rather than attempt to review and comment further on the entire document, I'll give you a flavour of its strengths and weaknesses by delving deeper into the section on security awareness training, an area of particular interest for me.

The PSR awareness section starts out quite well: 

"Security awareness training is an important element of protective security. It supports physical, information (including information privacy) and personnel security measures, as well as informing staff of the security governance requirements within their organisation."

The PSR goes on to recommend that "Security education should:" [with my comments added]

• be ongoing [presumably meaning continuous/year-round, not sporadic/once-a-year or even less frequently]
  
  
• be provided to all staff [but not managers? Later text mentions that awareness should involve contractors and security-cleared people but fails to address the managers or professional explicitly, a significant oversight if it is interpreted to mean that it only applies to staff]
  
  
• be designed to promote a sense of personal responsibility for effective security, regardless of position, grade or level of access ['a sense of personal responsibility' hints at the security culture which is mentioned later, although I wish it had gone further still by promoting demonstrable improvements in behaviour rather than just changing attitudes or beliefs]
  
  
• help [to] counter threats through imparting a basic knowledge of security principles [there's more to information security than countering threats per se: reducing vulnerabilities and impacts are at least as important if not more so.  'Treat risks' might have been more accurate than 'counter threats'."

I'll ignore the apparent confusion between awareness, training and education which are, in reality, distinct approaches with differing aims and methods as explained so eloquently in NIST SP800-50. At one level, it's merely a semantic issue, a common one at that.

The suggested content for awareness programs is rather basic although there's nothing to stop 'agencies' (i.e. users of the PSR) elaborating on the final bullet point's "additional security briefings" and being far more creative in the types of awareness activity and materials. I heartily recommend taking a much broader perspective on information security, going well beyond the largely legal compliance matters specified. There's much more value to be gained from strong information security than simply avoiding legal/regulatory breaches and hence not embarrassing the minister, important though those objectives might be in the government context (as we know from "Yes, Minister"). I'll mention just a single example for now: business continuity. Having narrowly scraped through the Christchurch earthquakes, I would have expected the government to be crystal clear about the value of resilience and recovery arrangements for vital information, processes and systems, but perhaps this is covered elsewhere? As a consumer of NZ government services, and tax payer, I sincerely hope this is one area in which NZ leads the world, with the possible exceptions of Sendai in Japan, Banda Aceh in Indonesia, oh and California.

Rebecca Herold offers excellent advice on the design and coverage of awareness programs.

A curious emphasis on 'personnel security' (which in practice means compliance with health and safety obligations) in the second half of the awareness section makes me wonder if it might perhaps have been derived from a health and safety awareness policy donor/template, or by someone with experience in that particular field. To be clear, there are health and safety aspects to information security (e.g. protecting secure computer suites against fire, providing fire exits, securing safety-critical building, machinery and vehicle controls etc.), plus environmental protection, plus risk management, compliance, governance and so on - it is just one of many objectives or constraints. On this aspect, the PSR feels somewhat unbalanced to me.

PS  I'm a little confused about the relationship between the PSR and the NZISM (New Zealand Information Security Manual). Perhaps at some point those two documents might either be merged into one or at least properly cross-referenced/hyperlinked from the relevant places? Given the chance, I would also suggest publishing the NZISM in the same online format as the PSR, rather than as a 500-page (!) PDF document - so 20th Century!

Management awareness paper on trade secret metrics

Protecting proprietary information, especially trade secrets, is - or rather should be - a priority for almost all organizations.

Trade secrets can be totally devalued if they are disclosed to or stolen by competitors, if that leads to their being exploited. The loss of competitive advantage can decimate an organization's profitability and, in the worst case, threaten its survival.

Availability and integrity are also of concern for proprietary information. If the information is destroyed or lost, the organization can no longer use it. If it is damaged or corrupted, perhaps even deliberately manipulated, the organization might continue to use it but is unlikely to find it as valuable.

Significant information security risks associated with proprietary information imply the need for strong, reliable information security controls, which in turn implies the need to monitor the risks and controls proactively. Being just 3 pages long, the awareness paper barely introduces a few metrics that could be used to measure the organization's security arrangements for trade secrets in 5 or 6 categories: its purpose is not to specify individual metrics so much as to lift the covers on a few possibilities. Your organization needs to determine its own security measurement objectives, adopting metrics that suit your purposes. Hopefully, this brief security awareness paper will stimulate thought and discussion on metrics: where it leads from there is down to you.

Management awareness paper on authentication metrics

User identification and authentication (I&A) is a key information security control for all systems, even those that allow public access (unless the general public are supposed to be able to reconfigure the system at will!). As such, it is important to be sure that I&A is working properly, especially on business- or safety-critical systems, which in turn implies a whole bunch of things. I&A must be:

• Properly specified;
• Professionally designed;
• Thoroughly tested and proven;
• Correctly implemented and configured;
• Used!;
• Professionally managed and maintained;
• Routinely monitored.

Strangely, monitoring is often neglected for key controls. You'd think it was obvious that someone appropriate needs to keep a very close eye on the organization's key information security controls, since (by definition) the risk of key control failure is significant ... but no, many such controls are simply implemented and left to their own devices. Personally, I believe this is a serious blind spot in our profession.  

If unmonitored key controls fail, serious incidents occur unexpectedly. In contrast, management has the opportunity (hopefully!) to spot and respond to the warning signs for key controls that are being routinely monitored and reported on using suitable metrics.  Security metrics, then, are themselves key controls.

The management-level awareness briefing paper briefly sets the scene by outlining common requirements for I&A. It then briefly describes four types of metric that might be used to monitor, measure and generally keep an eye on various aspects of the control. Perhaps the most interesting is the authentication failure rate ... but to be honest my thinking on metrics has progressed in the 7+ years since this paper was written. The metrics in the paper look naive and basic to me now. Since I'm updating the authentication awareness module this month, I'll be thinking up better I&A metrics when I rewrite the paper for customers ... perhaps even scoring them using the PRAGMATIC method ... oh and revising those awful graphics!

There's more to awareness than phishing

... at least 46 other things in fact:

1. Apps - about integrating information security into the software development/acquisition lifecycle, and mobile apps;
2. Bugs! - security vulnerabilities created by errors or flaws in program specification, design, coding or configuration by software development professionals and end-users;
3. Business continuity - business impact analysis, resilience, disaster recovery and contingency ;
4. BYOD (Bring Your Own Device) - the pros and cons of allowing employees and third parties to use their personal tablets, laptops, smartphones etc. for work purposes;
5. Change management - this module covers the intersection between change management and information security management, taking in risk management, compliance, patching, testing, configuration and version management, and more;
6. Cloud computing - covers the information security aspects of cloud computing;
7. Compliance and enforcement - fulfilling obligations under information security-related laws, regulations, standards, contracts etc. plus internal corporate policies, procedures and guidelines;
8. Computing on the go - securing portable ICT devices such as laptops, USB memory sticks, PDAs, smartphones and all manner of boys’ toys;
9. Cryptography - a fun, lightweight introduction to the rather heavy topic of encryption and other cryptographic applications;
10. Cybertage - ‘sabotage in cyberspace’ concerns the use of information and IT systems as weapons to commit sabotage, and sabotage of information and IT assets.
11. Database security - securing large collections of valuable data against hackers, corruption, loss etc.;
12. Digital forensics - forensic investigation of data relating to information security incidents;
13. Email - security aspects of email plus other electronic person-to-person chatting/messaging tools such as Skype, Instant Messager, Twitter, blogs and more;
14. Ethics and trust - trust and trustworthiness are closely related to ethics and morality;
15. Governance - roles, structures and reporting lines for the information security management function and its relationships with others such as risk management, IT audit and general business management;
16. Hacking - tips to counteract hackers, crackers, industrial spies, insider threats, scammers, criminals and other adversaries exploiting network, software, hardware and human vulnerabilities;
17. History of security - looks at the evolution of information security techniques and technologies through the ages;
18. Hi-tech infosec - risks and controls involving IT- or cyber-security;
19. Human error - explores the human side of information integrity including booboos, blunders and gaffes;
20. Human factors - the human side of information security - security culture, awareness, policies and more;
21. Incident management - the cyclical process for identifying, reacting to, containing, resolving and learning from information security incidents;
22. Information protection - obligations to protect information assets, plus information classification and baseline security controls;
23. Information Security 101 - a general, multi-topic starter module covering the basics of information security for new employee orientation sessions and to accompany the launch of your security awareness program.
24. Information security risk management - processes to identify, examine and treat the full spectrum of information security risks, in the context of corporate risk management as a whole;
25. Insider threats - security threats arising from employees on the payroll and third party employees working for/within the organization in a similar capacity;
26. IPR (Intellectual Property Rights) - protecting our own rights and interests while also respecting others’;
27. IT auditing - understand what makes IT auditors tick, what they do, and how to work with them more effectively;
28. Knowledge - protecting intangible information assets and intellectual property;
29. Learning from information security incidents - improving security in response to incidents that involve the organization, or indeed third parties (situational awareness);
30. Lo-tech infosec  - concerns those important parts of information security that lie beyond IT-security or cyber-security;
31. Network and Internet security - all manner of information security issues arising from networking and internetworking, the Web And All That, including the Internet of Things;
32. Office security - the average workplace faces a range of information security risks ranging from intruders, thefts, fires and floods to bugs and a variety of office IT security issues;
33. Oversight - a unique security awareness module covering both ‘oversights’ (casual errors, accidents and omissions) and ‘overseeing’ things (an integrity control);
34. Passwords - several modules concern the credentials used for identification and authentication of people, including passwords, passphrases, two-factor authentication, biometrics and so forth;
35. Privacy - protecting personal information and respecting individuals’ rights to privacy;
36. Physical security - protecting information assets (including people) against physical threats such as unauthorized or inappropriate physical access, fires, floods, and various workplace hazards is this month’s hot topic;
37. Portable ICT - security of laptops and other portable/mobile ICT devices, touching on BYOD and home working/teleworking;
38. SCADA/ICS security - security risks and controls relating to Supervisory Control And Data Acquisition/Industrial Control Systems on the factory floor as well as distributed and embedded microcontrollers such as those increasingly found in Building Management Systems, elevators and vehicles;
39. Secure-by-design - making information security an integral part of systems and processes from the outset, including security architecture and the concept of fail-safe/fail-secure design;
40. Social media - covers the security hazards associated with Linkedin, Facebook, blogging etc.;
41. Social insecurity combines social engineering with the security aspects of social networking and social media;
42. Surveillance - increasingly common in public, corporate and personal domains, surveillance is both a valuable form of monitoring control and a privacy/human rights concern depending on your perspective;
43. Survivability - tackles the extreme end of risk management, incident management and business continuity;
44. Third parties - information security issues resulting from business relationships between organizations, extending the corporate security boundary to suppliers, partners and customers;
45. Trade secrets - a spectrum of activities from legitimate market research and competitive intelligence through to unethical if not illegal industrial espionage and information warfare;
46. Viruses and other forms of malware (worms, Trojans, key loggers, spyware, rootkits, APTs/Advanced Persistent Threats) are such significant threats that we update this module annually with fresh content and news.  This year, we picked up on the sophisticated bank Trojans.

... so how come certain vendors are still desperately flogging the notion that self-phishing is enough?  Do they honestly believe that their customers are that naive?

Don't get me wrong: phishing is indeed a threat, but even a highly phishing-aware workforce remains open to many more forms of attack, and indeed many other forms of information compromise, damage or loss.

Lo-tech infosec

"Lo-tech infosec" is a brand new security awareness module to complement last month's one on hi-tech infosec.

There is no shortage of material: there's always loads to say about information security, especially once you shed the IT blinkers and think beyond the mot-du-mois "cybersecurity". 

Our prime focus this month is on people including social engineering, frauds and scams, human errors and mistakes. 

Physical security for tangible information assets merits a mention, along with governance and compliance, and - yes - the value of security awareness as a control.  Even industrial relations, health-and-safety and HR practices are part of the mix, plus good ol' yuman error.

Management awareness paper on insider threat metrics

How do you measure 'insider threats' in your organization?  If your answer is "We don't!", then I have to wonder how you are managing insider threats. 

Without suitable metrics, how do you figure out how much of a problem you might have from employees, contractors, consultants, temps and interns?  How do you determine where best to spend your security budget? How do you persuade management to loosen the purse strings sufficiently to address the risks?  I guess you guess!

The discussion paper breaks down 'insider threat' into chunks that can be measured sensibly.  The main divide falls between deliberate attacks (such as frauds by insiders) and accidents (such as mistakenly overwriting the entire production database - don't laugh, it happened to me 25 years ago and the nightmare still haunts me today!). 

The paper picks up on one of the most productive sources of information security metrics: the IT Help/Service Desk's problem and incident management process.  Most mid-to-large organizations these days route employee queries and problem reports through a centralized helpdesk function that acts as a clearing house, offering first-line support and routing unresolved calls to the appropriate resolving agencies for specialist help.  A valuable core part of their role is to ask questions and record information about calls in the ticketing system, tracking the calls through to completion.  The system, then, is a goldmine of information about queries, problems, events, incidents and other issues, including "near misses" (assuming the organization is sufficiently clued-up to encourage workers to report close-shaves as well as actual incidents).

If this is all Greek to you, find a spare hour or two to speak to a helpdesk supervisor about the call-ticketing system, about how calls are categorized and recorded, and how to squeeze suitable reports out of the system ... but, before you get completely carried away on a wave of enthusiasm, planning how to use all that sexy statistical and textual information, think very carefully about what you are doing.  The availability of information is not, in fact, the main concern when designing security metrics.  A far more important issue is to figure out what you want to know, what questions need to be answered.  Conceiving questions that fit the available answers is putting the cart before the horse.

Management awareness paper on network security metrics

Measuring network security involves, first and foremost, determining what 'network security' encompasses, and how it relates to the business.

Writing way back in 2007, we said that network security "comprises a range of technical and procedural controls designed to prevent, detect and/or recover from security incidents affecting the corporate data networks – incidents such as unauthorized access (hacking), worms and other malware infections, and unplanned network downtime". The context for the paper was a security awareness module exploring security arrangements protecting data networks against both deliberate and accidental threats.

The paper described ways to measure network security incidents, controls, risks, compliance and governance.  It ended with an upbeat conclusion and call-to-action: "Do not neglect the value of having the experts present and discuss reports with management.  The dialogue that ensues adds value to the written reports.  Why not present and discuss these ideas with your management and seek their opinions, bringing to the table some prototype reports in one or more formats to stimulate discussion and clarify their objectives?"

The PRAGMATIC approach is a structured, systematic way to consider the pros and cons of various metrics, leading ultimately to a decision on which ones (if any!) to adopt.  Just as important as the final destination, the method leads managers and infosec pro's together on a journey of discovery.

My guess is that the network security incident and compliance metrics would probably score above the others proposed in the paper but I can't tell for sure because I don't know a thing about your situation or measurement needs: your evaluation may well come to a markedly different conclusion.  Furthermore, in discussing the metrics paper, you might come up with 'variations on a theme', meaning variants of the metrics proposed that would score more highly, and perhaps something completely different, especially if it turns out that none of the metrics in the paper are suitable.  

That spark of creativity is the real power of PRAGMATIC.  Scientifically analyzing the factors determining the strength and suitability of the metrics under discussion leads to a better understanding of the metrics and of the measurement needs.  Contrast that with the blank-sheet approach.  Faced with the question "What network security metrics shall we adopt?", most business managers would be at a loss to know how to proceed.  If the security, network or IT people suggest one or more technical security metrics to fill the void (perhaps plucked from the air or picked out of some banale list with a pin), the managers don't have the basis for evaluating them, meaning that they are quite likely to accept whatever is offered, perhaps later coming to realize that they aren't exactly ideal.  If the metrics truly don't work, it's back to the drawing board to pick some more ... assuming someone has the good sense to call a halt to the senseless waste of time and effort (that's not a facile comment: many organizations drift aimlessly along for years with inappropriate, unsuitable or low-value metrics because everyone assumes someone else must be using them!*).

Although it is possible for the organization to develop a decent set of metrics by sheer trial-and-error, there is a distinct chance that good metrics will be discarded or discounted for arbitrary reasons, and that opportunities to 'tweak' metrics the better to fit the business needs will be missed.  Using the PRAGMATIC method as a systematic process to select, develop and maintain suitable metrics has to be a better way, don't you think?

* That reminds me: have you audited your organization's security metrics? It may be a tedious assignment but a competent and diligent auditor should be able to follow the paper trail from gathering the source data through analysis and reporting to the decisions arising - if any.  If the trail goes cold, that's a strong indication that the metrics are simply not working, implying not just a waste of effort and money but an information void and lost opportunity.  Low quality metrics are a costly distraction, literally worse than useless!

PCI embraces security awareness

The PCI Security Standards Council's Security Awareness Program Special Interest Group has released an 'information supplement' to PCI-DSS, suggesting an awareness approach that is remarkably similar to ours.

Best Practices for Implementing a Security Awareness Program is a well-written guide elaborating on four key ideas:

1) Security awareness is a vital tool supporting the business. "It is therefore vital that organizations have a security awareness program in place to ensure employees are aware of the importance of protecting sensitive information, what they should do to handle information securely, and the risks of mishandling information." [We go further in emphasizing the business value of information security, for example giving management confidence that information assets will be sufficiently well protected when exploring new business opportunities.]

2) Security awareness is best delivered on a continual basis, all-year-round. "Security awareness should be conducted as an on-going program to ensure that training and knowledge is not just delivered as an annual activity, rather it is used to maintain a high level of security awareness on a daily basis." [Absolutely! Our monthly deliveries are explicitly intended to support the continuous, rolling approach to awareness.]

3) Security awareness should address three audience groups, namely all personnel (with the aim of making security a habit), plus managers and personnel in 'specialized roles' meaning those who work directly with card holder data (both of whom need additional information/guidance). [Our three streams address personnel in general, managers and specialists with a professional interest in information security.]

4) Security awareness content needs to be delivered through a variety of suitable mechanisms throughout the organization, implying that over-reliance on a single channel (such as email, posters or the intranet) is less than ideal. [Our monthly modules deliver 20-30 different formats of material, all consistent, covering the same subject area, at the same high level of quality, and fully customizable. Our customers have enormous flexibility in their approach to awareness, while we support awareness programs at every stage of maturity from the basics to the most advanced.].

The remainder of the guide is not quite as impressive. It goes on to suggest the awareness topics, diving into the specific information requirements relating to PCI (alone). "It is recommended that general security training for all personnel include defining what constitutes cardholder data (CHD) and sensitive authentication data (SAD) and the organization’s responsibility to safeguard both. A high level overview of the importance of the PCI DSS may also be included; to ensure personnel fully understands the purpose behind an organizational policy to safeguard cardholder data. To ensure all personnel are engaged stakeholders in the security awareness program, the roles and responsibilities of all staff to protect CHD and SAD should be outlined during all security awareness training, in accordance with organizational policy." The guide mentions need to protect all forms of information (not just computer data, media and systems), to address social engineering, and to make personnel aware of policies and procedures. [We cover more than just PCI. We take a far broader perspective on information security because many information assets (not just credit card details!) are highly valuable to the organization, and all of them deserve or require adequate protection. Furthermore, the organization's information security-related compliance obligations go well beyond PCI-DSS. As far as we and our customers are concerned, PCI is just one of many obligations - merely the tip of the iceberg.]  

The guide also suggests some metrics, divided into two groups. The "Operational metrics" groups appears to be a random and incomplete assortment of security control objectives (labelled "Metrics") and measures (labelled "Training effectiveness indicators"): neither are much good, in my opinion, since they don't directly and obviously relate to business objectives. For example, "Reduced system downtime and network or application outages" is clearly a technical/IT objective, whereas the corresponding business objective (presumably something like "Highly available IT systems and networks suporting critical business activities") remains unstated, while the suggested measure "Consistent, approved change-management processes; fewer malware outbreaks; better controls" is merely another incomplete set of technical objectives. The other group, "Training program metrics" barely even relate to the objectives of the awareness program stated earlier in the guide. All in all, I highly recommend skipping the metrics section completely. [Read my book PRAGMATIC Security Metrics instead!] 

There are a few references in the guide for further information. Despite us having been doing this stuff consistently since 2003, I can understand them not even mentioning us but it is very disappointing that Rebecca Herold's bible on security awareness was not cited ... which seriously leads me to wonder about the Special Interest Group which produced the guide. Surely someone among the august group of 100 or so organizations has read Rebecca's book and seen the light? Or are they all still floundering along in the dark?  :-)

Management awareness paper on malware metrics

Malware - malicious software - encompasses a variety of computer viruses, Trojans, network worms, bots and other nasties.  

Malware has been the scourge of IT users ever since the Morris worm infected the early Internet way back in 1988.  Despite the enormous global investment over the intervening years in information security controls against malware (including security awareness!), it remains a significant security concern today. 

Although antivirus software companies sometimes admit that they are fighting a losing battle, malware is generating so much income both for the VXers (malware authors) and their criminal masterminds, plus the antivirus software companies, that the arms race looks set to continue for the forseeable future.  Both sides are constantly investing in new tricks and techniques, fuelling a thriving black market in zero-day exploits and novel malware.

Meanwhile, the rest of us are lumbered with paying for it in one way or another. Addressing the malware risk is more involved than simply throwing money at antivirus software: malware metrics are the key to understanding the balance of risk against control, investing wisely, and doing our level best to keep up with, if not stay one step ahead of the game in this dynamically evolving situation.

Download our third security metrics awareness paper here.

Management awareness paper on database security metrics

The next security awareness paper suggests to management a whole bunch of metrics that might be used to measure the security of the organization's database systems.

Most information-packed application systems are built around databases, making database security a significant concern for the corporation.  We're talking about the crown jewels, the bet-the-farm databases containing customer, product and process information, emails, contracts, trade secrets, personal data and so much more.  Despite the importance of database security, we don't know of any organization systematically measuring it ... although we do know of many that struggle to keep on top of database security design, development, testing, patching, administration and maintenance!

So how exactly are management supposed to manage database security without database security measures? Extra sensory perception, perhaps, or gut-feel? Either way, it's hardly what one might call scientific management!

New hi-tech risks awareness module

In the 11 years that we’ve been providing the awareness service, it has grown substantially in both breadth and depth. We’ve covered risk management as a discrete topic a few times before, while information risk is the foundation for information security and hence virtually all the security awareness modules.  This month, however, the latest addition to our bulging portfolio of security awareness topics concerns the central yellow area of the scope diagram shown here.

A large proportion of information these days is communicated, processed and stored using IT systems and networks.  There are numerous risks associated with IT which are central to this awareness module.  However, it makes little sense to discuss IT or tech risks in isolation since it is the possible adverse consequences on the business that determine whether or not they are a genuine concern.  If there were no impacts, the risks to the organization would be negligible.

“Hi-tech risks”, then, arise where the business intersects both IT and information security.  They involve security threats to information assets exploiting vulnerabilities within the technology leading to adverse impacts on the business.  [Some involve the use of technology as weapons - another facet to hi-tech risk mentioned in the awareness materials.]

Thinking more broadly, information is a valuable corporate asset that deserves and requires protection against various risks, particularly those that affect its confidentiality, integrity or availability.  Protecting information is challenging due to its intangible and ephemeral or dynamic nature.  Information is subject to a wide range of threats, while there are numerous vulnerabilities that might be exploited and the impacts or consequences of incidents vary markedly.

To complicate matters still further, information-related risks are ever-changing, and despite our best efforts we can never have perfect knowledge about them: there will inevitably be situations that we did not predict and incidents that we did not completely guard against.  Hence information risk management depends on the quality of the information concerning information risks (yes, that is self-referential!):

That's one of the simple diagrams we used to put this potentially quite complex subject across to management - not because managers are "simple", you understand, but rather they need to see past the tech content to appreciate the business implications.  

Finally, information and technology risks have to be managed alongside financial risks, market risks, product risks, strategic risks, personnel risks and so forth.  From senior management’s strategic viewpoint, they all have to be managed to a comparable degree ... which implies things such as consistency of risk management approaches and terminology, and preferably also risk metrics, otherwise we're asking them to compare oranges with apples when determining whether the risks fall within their risk appetite.  The security metrics paper in November's awareness module suggests several ways to measure tech risk that can also measure other forms of risk.

PS  You'll understand why we named this module "hi-tech risks" when you see next month's.

Management awareness paper on IPR metrics

When we get a spare moment over forthcoming months, we plan to release a series of awareness papers describing metrics for a wide variety of information security topics through the SecurityMetametrics website.

The first paper, dating back to 2007, proposes a suite of information security management metrics relating specifically to the measurement of Intellectual Property Rights (IPR). Managing and ideally optimizing IPR-related controls (namely the activities needed to reduce the chances of being prosecuted by third parties for failing to comply with their copyright, patents, trademarks etc. plus those necessary to protect the organization's own IPR from abuse by others), requires management to monitor and measure them and so get a sense of the gap between present and required levels of control, apply corrective actions where necessary and improve performance going forward.

These metrics papers were written for managers.  Their primary purpose is to raise awareness of the monthly topic, but really we hope to encourage information security professionals and management to think about, discuss and perhaps adopt better security metrics.  

If you follow the sequence, you'll notice our own thinking change over the 7 years since this first paper, particularly while PRAGMATIC Security Metrics was being written.  From time to time, we introduced new styles of metric, often covering the same information security topics repeatedly but from slighly different angles (there are already 50 infosec topics in our awareness portfolio, with about 20 more to come).

To eat a chocolate elephant, take small bites

Instead of, or rather as part of, fostering a corporate security culture (a grand but nebulous objective), identify specific aspects or elements of the culture that most need to change and work on those more constrained issues. 

For clues about which aspects need addressing first, speak to your IT auditors and check the security incident reports and security metrics.  For example, if the organization has a longstanding, seemingly intractable problem with noncompliance in the security domain, focus on compliance awareness.  Get some traction on that, measure the improving awareness levels, and move on to the next topic.

You can get as detailed and specific as you like in your planning.  Is the noncompliance problem mostly about legal and regulatory obligations, or policy compliance, or contractual compliance, or something else?  Is it all about privacy, or are there other compliance concerns such as governance and intellectual property rights?  Which parts of the business are the worst?  What have the noncompliance incidents, enforcement/penalties and compliance efforts cost the company to date, and which were the most costly types of event?  Are there particular layers (such as junior management), departments (such as Procurement) or business units (such as, say, some far-flung office that pays scant attention to corporate directives) that lag the field?  Awareness surveys and various other PRAGMATIC information security metrics will enable you to answer such questions and generate a credible basis for planning - also by the way a means to manage, maximise and ultimately demonstrate the value of your awareness activities.

Alternatively, don't worry so much about the micro-topics and the delivery sequence but take a longer term view.  Concentrate instead on the breadth of coverage, the quality of the materials and the effectiveness of your awareness program. Your organization will be relatively aware of some of the information security topics we cover, which is no bad thing. Our stuff will reinforce and encourage secure behaviors, and we may well come up with novel angles that you hadn't even considered. For instance, do your security compliance activities pay any attention to business partners' compliance with the obligations your organization imposes on them?  We'll help you pick up on all those issues and more.  Over time, we'll help you consume your choccy elephant.

So what are you waiting for?  It's not going to eat itself.