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.