Jim the attendant looked me up on his computer and discovered that there had been no payments from my VISA account since last November: I owed six months of fees! Jim explained that there had been “some problems” with their admission and billing system after an upgrade in January, but that the problems were resolved now. He agreed that allowing members to default on their monthly dues was a serious threat to cash flow for this small organization. It seems that the software was supposed to issue a warning automatically to members about delinquent payments, but that part of the code never activated.

After paying the accumulated fees, I thought about how dangerous this glitch – this anomaly – was. This health club has a sign-in that uses a card swipe to bring up the members account on screen and shows a photo of the authorized user of the account – all in aid of user identification and authentication to prevent free riders who might share a single membership. In previous discussions with managers, I’ve urged them to monitor their records carefully for customer-relationship assurance; for example, if I were running the club, I’d bring up an exception report whenever any member’s attendance figures dropped below a proportion of their normal activity. Someone who works out every day hasn’t shown up for a week: are they ill? Are they on a trip or on vacation? An e-mail expressing concern would be a nice touch; perhaps the managers would respond to a sickness by offering the customer an extension on their account – you don’t use the system for a month, you get the deadline extended by a month. Note that the critical issue in such a system is to define the anomaly in terms of what’s normal for the specific member, not in terms of a general average. Thus if someone comes in once a week and misses a month, then perhaps that situation would prompt an enquiry.

I’ve taught students for decades that they should be paying attention to anomalies. Anomaly detection depends on adequate data gathering and statistical analysis – or even just graphical representation of the data. For example, the following diagram shows a typical anomaly: a change of slope.

In the diagram, the three blue lines at the bottom represent some normal changes in a resource; e.g., disk-space utilisation. The graphic reminds me of a good real-world illustration of the value of paying attention to anomalies.

Back in the mid-1980s (my goodness, almost 40 years ago!), I was the director of technical services for a computer time-sharing service bureau (we served 28 insurance companies and insurance brokerages) in Montréal, Québec, Canada. I remember a specific incident where I was using a graph with lines for disk space utilisation (when a huge HP7933 disk drive had 404MB – yes, megabytes, children, not terabytes) by different customers. In the case I am remembering, a customer’s disk-space began growing at a furious rate (represented as the continuous red line in the diagram). The inflection point is where the slope in disk utilisation changed from the A-A’ line to the B-B’ line. Any time there’s an inflection point, resource managers should become curious: what’s happened to cause the inflection? Because I routinely monitored CPU utilisation and disk-space utilisation among other parameters, I spotted the change quickly and investigated. It turned out that programmer at the customer site had REMmed (commented out – from REMark) the instructions in the job control language (JCL) for a particular batch job so that temporary files wouldn’t be deleted at the end of the job. After he ran his diagnostics, he forgot to remove the REMs. By the time I caught the anomaly, the client had about 20,000 temp files in their account. (By the way, that programmer should not have been using production code to run his tests.)

Even if a change in slope is not due to an error, noticing and investigating an inflection point is a good idea. For example, it could be that a new routine has been implemented on the date where the slope has changed; in that case, system managers would want to notice the change in resource consumption and plan for orderly resource management (such as ordering new resources earlier or later than planned).

From an information security perspective, inflection points in resource utilisation can signal information system security officers (ISSOs) that something unusual has happened or that a norm is being redefined. For example, suppose that the graph above represented accumulated CPU utilisation or bandwidth utilisation for individuals or for specific workgroups in an organization. Wouldn’t any ISSO want to know why there was a change? What if it were an unauthorized change? What if the system had been infected by botnet malware and the increased bandwidth was due to 10,000 spam e-mails being sent out per hour on a rogue Simple Mail Transport Protocol (SMTP) server?

Another example: Joe the accountant has never logged into the network after working hours in the last six years of record-keeping; so what is happening when “he” starts logging in at 03:00 every day and is generating GB of data transfers? Wouldn’t an ISSO want to check with Joe about what’s up? And wouldn’t it be important to discover that Joe has no idea what the ISSO is talking about? Aha! Unauthorized access: hacker at work.

Anomaly detection using resource utilisation data can’t be invoked suddenly: unless there are accumulated data allowing analysts to establish norms, it may be difficult or impossible to distinguish random fluctuations from systematic changes. For those interested in automating their analytical tools, one would compute linear or nonlinear regression coefficients for moving subsets defined by some reasonable period (as a function of the intrinsic variability of the data) and note changes automatically for alerts to be signalled to the resource managers or ISSOs. Readers will want to consult any textbook of applied statistics for details.

So to sum up, keep track of resource utilisation and investigate anomalies!

Advanced persistent threats (APTs) attack with privilege escalation and operate through application accesses that, to network monitors, appear to be fully normal in terms of network source addresses, protocol syntax-correctness, and user authentication / authorization levels. Both detection and remediation of these attacks are critical business objectives; whether driven by regulatory or operational sensitivities, data privacy and application security must be maintained and the flow of data must continue without interruption.

Detection

In order to reliably detect APT behaviour as it happens, it is necessary to analyse network traffic at the stream level.  The most effective approach to accomplishing this is to perform continuous inline analysis of all traffic on network links which access critical servers and information resources. This approach would be equally suitable for both enterprise networks and industrial supervisory control and data acquisition (SCADA) system networks.

The Bayshore Networks white paper “Advanced Persistent Threat: From Detection to Remediation” (available with simple registration) discusses three essential elements to consider for mounting an effective APT defence:

1. Establish a pervasive network presence (sometimes called a “secure network fabric”) which requires that a protocol-inspection capability be present on all links in a complex application structure.
2. Conduct deep protocol analysis, which requires a Layer-7 analysis of protocol streams, not just packet analysis. The stream inspectors must be able to isolate all elements of a data protocol, especially those containing data inputs from clients.
3. Incorporate heuristic baselining. The application inspection system must construct a rich and multidimensional baseline of the behavioural patterns of each application, and store the baseline in a database that can be continuously added to. The database is then used to detect anomalous behaviour in real time. The detected anomalies are often indicative of APT attacks in progress.

The biggest operational challenge with baselining a large number of applications is the need for automation. There are various tools available to help with this, including certain open-source software [1] and enterprise applications [2], most of which have some degree of default rule sets and best practices already in place. There are potential problems with some of these, however, such as reporting false positives. There are also architectural considerations and requirements that need to be looked at very closely such as multiple protocols, dynamic routing, scalability, manageability, and cost-effectiveness.

Making It Work In Practice

Applications contain errors and security vulnerabilities that can be leveraged by attackers to compromise other applications. The threat can be reduced by manually scanning and remediating problems at the source-code level in each application, but this is expensive and time-consuming at best. At worst, it’s impossible due to the lack of access to application source code or technician availability. Application scans and audits provide no overall security assurance unless all the applications are regularly scanned and audited.

The most effective defence against APT is to collect heuristic profile data on all applications, focusing alert-response activities on those applications that are the most valuable or have the highest security-sensitivity or regulatory exposure. The objective is to provide measurable improvements in the operational availability of applications by inhibiting the attacks that compromise their integrity.

Application behaviours exhibited by determined persistent attackers are different enough from expected behaviours to be detectable with a high degree of confidence by comparison with heuristic baselines. This confidence is particularly true for the behaviours associated with the foot-printing and scanning phases of APT attacks. Executing this analysis in real-time has proven to be generally non-disruptive to application performance.

In a private cloud environment, for example, the range of possible vulnerability probes is multiplied by the topological proximity of applications, combined with the widespread use of common authentication and authorization platforms like Microsoft’s Active Directory™ and CA’s Netegrity™ product (SiteMinder). Proximity makes it easy for an attacker to reach multiple systems from a small number of compromised hosts, and common authentication means that the stolen or hijacked privileges can often get the attacker into those systems.

Real-time detection of behavioural anomalies can be readily used to block or fuzz these behaviours, thus inhibiting or retarding attacks on applications. The practical limitations of this approach are associated with the fine-tuning of automatically-collected behavioural metrics to filter out the learning of bad behaviours (reducing missed true negatives), and to complete the learning of correct behaviours (reducing false positives).

Information assurance policy, itself, must be heuristically-based and easily extended by both manual and automatic processes. Traditional and non-traditional security methods, including packet filters, intrusion detection system (IDS) products, and next-generation firewalls, provide significant value in high-end networks. But they do not, and cannot, provide the full range of information-assurance features needed to address today’s security challenges.

ADDITIONAL NOTES:

[1] See, for example, KoreLogic’s FTimes & WebJob, and CFEngine’s Community.

[2] E.g., Symantec Automation Suite, TripWire Enterprise, and BMC to name a few.

* * *

Francis Cianfrocca is Founder and CEO of Bayshore Networks, LLC which specializes in high-end IA products for a wide range of applications. Mr Cianfrocca is a noted expert in the fields of computer-language design, compiler implementation, network communications, and large-scale distributed application architectures. He has worked for a number of different companies either directly or as a consultant including Bank of New York, Gupta, McDonnell-Douglas and New York Life. A very strong advocate of open-source software development, he created several widely-used open projects, including the Ruby Net/LDAP library, and the EventMachine high-speed network-event management system. He is also a talented musician who attended the Eastman School of Music in the Music History department and studied for his Master’s Degree in Orchestral Conducting at the University of Michigan. Mr Cianfrocca is a member of the 2000 class of Henry Crown Fellows at the Aspen Institute

* * *

Copyright © 2012 Francis Cianfrocca & M. E. Kabay. All rights reserved.

Permission is hereby granted to InfoSec Reviews to post this article on the InfoSec Perception Web site in accordance with the terms of the Agreement in force between InfoSec Reviews and M. E. Kabay.

It was a big project for a homeowner. My friend set out to design, dig and decorate a fish pond out in her back yard. She dug the pond by hand, with her mother directing her in how to construct up from the bottom depth and sculpt the sides of the pond. She went to local rock and building supply stores to find just the right rocks to decorate the pond’s margins. Careful planning went into designing the plant-scaping of the pond. Shorter plants were set around the pond’s edges and, since they wanted the pond to attract birds, they made especially sure that there was at least one shallow area where the local birds could bathe easily.

They deliberately built deep areas into the pond, because the winters in the area can be quite cold, with temperatures at freezing and below for weeks at a time. The pond owner wanted the fish to overwinter in the pond, so the deeper areas allowed a place for the fish to avoid the colder upper waters. The deepest areas measured between four and a half to five feet.

I was close by at the time and watched the project progress, from first shovelful to adding the finishing touches such as floating night lights and landscaping with carefully selected rocks and rosebushes. And I had the privilege of attending their first-ever “Pond Party” where everyone was invited to bring not a covered dish, but a live fish to add to the pond, for colour and population.

Once the project was complete, the pond was a centrepiece in the yard, a haven of life, sound and colour, with the soothing sound of the waterfall cascading into the pond and the bright flashes of orange, black and white from the goldfish and koi living in its waters.

But, even a backyard project like a fish pond would have benefitted from a risk assessment and the advice of an experienced pond builder who fully understood the risks and vulnerabilities of having a fish pond in the yard.

My friend knew the problems of having dogs in the area, since two of her acquaintances owned Labrador retrievers that loved to leap into the pond on sight. However, there were additional, unplanned risks that eventually surfaced just over four years later.

It was the long Fourth of July Weekend. My friend had taken her boyfriend and dog to go camping in the mountains; they left on Friday night. I lived in her house part-time, and had decided to stay in her house part of the weekend to keep an eye on the place, arriving on Saturday afternoon.

On Sunday, the next morning, I went into the kitchen shortly after seven o’clock a.m. to prepare a pot of coffee. As I leaned toward the window overlooking the pond, I saw a huge set of wings flapping slowly next to the pond. A massive great blue heron rose elegantly into the air and flew away. His wingspan was at least five feet. I was thrilled for half a second, but my thrill melted into abject horror when I realized that he had been actively pursuing the fish in the pond! Feeling a little queasy, I delayed going out to take a look at the pond, fearing what I would see and knowing that I couldn’t do anything if any fish were gone.

Finally, when I went to check the pond with a gnawing ache in the pit of my stomach, the only fish that appeared to be left in the pond were the two large koi named Midge and Matsui. If I have ever seen fish that look frightened, those two looked terrified. The koi are larger fish, so I surmised they might have survived more easily, due to their size. The smaller fish were gone, all of them. I was saddened for the entire day.

* * *

From an information assurance prospective, the pond was built without a thorough risk assessment. While the original pond advisor had some great ideas, not all of the risks had been factored in when building the pond. A professional pond installer might have advised installing anti-heron fences, or motion-sensing water spray devices that scare cranes and herons away from fish ponds. (If one searches YouTube.com for videos about herons raiding fish ponds, there are some hilarious videos of failed fish pond protections. Apparently, herons regularly scope out an area for ponds and open water and are always ready to ‘dive in’ at an opportune moment.)

Thus, a pond-risk-assessor would have advised building the pond with more hardened, protective coves for fish to hide from predators. This all could have been arranged after a complete, knowledge-backed pond risk assessment.

This is how it should be in information technology. An information system should be evaluated up-front before build out. Experienced information assurance professionals should be called in to sit down with business and process owners, the systems should be evaluated regarding the most critical components and protected accordingly. And, as in our fish-pond example, system owners do not always have a full picture of the risks involved in operating an information system. Without a, ah, full-scale risk assessment, critical risks could be overlooked with disastrous results.

There was one inadvertent protection that my friend had that worked to shield the pond from previous heron attacks . . . her dog. The fact that the dog went outdoors and spent time around the pond was duly noted by the ever-watchful herons.

One last mention, about five weeks after the great blue heron visited my friend’s pond, I got an excited phone call. My friend breathlessly told me that the goldfish had appeared in the pond! All of them!! Apparently experts at self-preservation, the goldfish and smaller fish had dived down to the deepest area in the pond (over four feet), and stayed there for over five weeks, waiting for the all clear. And sure enough, there they were, unharmed and freely enjoying their pond environment.

Hmmmm, maybe that’s a way to protect data, too . . . data that protects itself by diving into a deep cryptographic pool when attacked; but that’s another article.

* * *

Jan Buitron took her first computer class in 1989, launching a long career in Information Technology.  Starting in Technical Support, she methodically progressed from providing level 1 to providing level 5 support and beyond. She relentlessly pursued industry certifications, starting with two full Microsoft MCSE certifications, along with CompTIA’s Network +. She attained the CISSP in 3.5 months. Most recently, she passed the ITIL v3 and CISM exams.

During seven years at IBM, she was introduced to information assurance as an Access Control administrator. Continuing her IA career, she participated in a Security Operations Center there, as well. Her experiences there prompted her to pursue a Master’s Degree in Information Assurance (MSIA) from Norwich University, which she finished in 2009.  She has since worked in IA for six different government agencies and the DoD

Jan currently teaches for Regis University as adjunct professor in their Masters of Science Information Assurance Program, teaching classes such as Information Security in the Enterprise and Computer Forensics.

She is an accomplished writer, with several articles in Network World.  She wrote the soon to be published chapter covering security and privacy concerns in social networking for the 6th edition of the Computer Security Handbook, (Wiley). Her near-term plans include a PhD in Information Assurance.

Spiral development teaches us to incorporate the Pareto Principle (the 80/20 rule) into any project. If much of the desired result can be achieved with modest effort / resources / time, then it makes sense to get a first-cut version of any project in place before trying to refine it. Effective risk management takes advantage of incremental gains by instituting the best available defences and policies and then improving them; “lessons learned” is often used in after-incident reports (post mortems) on such systems. It would be ridiculous to have no defences or policies because they wouldn’t be perfect.

When I proposed the Master of Science in Information Assurance to the University Curriculum Committee at my university in 2002, I was astonished at the reaction of a humanities professor. He said that there was insufficient evidence from scholarly research to be able to judge the proposals, and therefore, the entire project should be delayed for at least a year as we provided the Committee with additional grounds for believing that the program would be successful. Luckily, I convinced the rest of the Committee that we would be revising the program constantly (continuous process improvement again) and would learn from experience.

And that’s what we did: we accepted a first class of 15 students in September 2002 and have been revising and adapting ever since.

Recently I was thinking about how these principles from systems engineering and information assurance can be applied constructively to ordinary life. I was prompted by memories of a discussion with an old friend many years ago about taking care of his disabled daughter after he died. To my surprise, I had ended up using the principles described above in our discussion of his will. I’ve changed identifying details in what follows to protect his survivors’ privacy.

Bob, now deceased, was then a 95-year-old retired history professor from a Midwestern university. He and his 93-year-old wife Frannie had discovered that their daughter Judy, then in her sixties, suffered from a severe personality disorder that had put her on psychiatric disability from the state where she lived for many years. She could live by herself only with great difficulty.

In our discussion, I asked what measures had been put in place in Bob and Frannie’s wills to ensure that Judy could be financially secure after her parents died. To my horror, Bob said that they were still thinking about it. They wondered how to insulate Judy from her own tendency to become obsessively committed to particular political causes; they thought that if she gained access to a lump sum of inheritance, there were good chances that she would impulsively give it away to her favourite political action group (she was particularly concerned with wildlife preservation) in an emergency. Bob and Frannie were also devoted supporters of good causes, but they worried that Judy would be destitute, with no provisions for her own well-being.

Bob emphasized how he and Frannie had been “thinking about” the problem for a decade but still had not decided on the “perfect solution.” I was horrified. I insisted that as Voltaire wrote, the perfect is the enemy of the good; waiting until all possible objections and eventualities were resolved could result in never actually acting at all. Indeed, Bob and Frannie had not included any details about how to protect Judy against her own mental disabilities in their will because they did not want to offend her.

For example, in Bob and Frannie’s case, it would have been a good idea to have a will in place assigning Judy a trust fund from which she could draw periodically (every month, maybe) under the control of an executor rather than allowing the inheritance to be delivered to her in a lump sum. With that safety-net in place, the parents could then work on improving the arrangements. But not having anything in place was asking for trouble.

And trouble there was.

Bob died in 1998 and Frannie, as is so common, died shortly thereafter. They had never completed their will, so Judy inherited the estate in toto. When 2001’s terrible events of 9/11 occurred in New York, she was so moved that she gave away the totality of her inheritance to help victims and their families – admirable and loving, but she was left to survive on a pittance from the state. She was eventually thrown out of her apartment because of a citation from the public health officers in her city when her landlord reported that her obsessive hoarding had resulted in a dangerous situation – her apartment was crammed floor to ceiling and wall-to-wall with hundreds of disintegrating cardboard boxes full of old clothing, useless crockery, and ancient magazines. Apparently she had even dragged in a filthy, stinking, soiled mattress salvaged from a garbage pile “because it might be useful.” She disappeared after the eviction and no one knows what happened to her or whether she is still alive.

The principles of spiral development apply not only to software engineering, business continuity planning, and disaster recovery: they can be helpful in any enterprise where we are developing something new or unique and cannot simply apply an existing model to meet our needs.

Don’t let the quest for an illusory perfection ruin a perfectly good project. Get on with the best you can do and adapt. Remember: Reality Trumps Theory!

I was delighted to see that my brainwashing, er, education in principles was having such an effect on our students. The phrase “Reality trumps theory” became the motto for the master’s program in IA that I designed and helped to establish in 2002. As the students correctly explained, I have a deep suspicion about absolute rules divorced from the particular details of the problem confronting us. For example, one can easily find a perfectly good principle being turned into rigid dogma; consider “Change your password frequently.” I have encountered organizations where the IA or IT staff have dictated monthly changes in logon passwords despite the consequences: employees either chose a ridiculously simple, easy-to-guess passwords or they wrote down complex passwords on papers and stuck them in obvious places such as underneath their keyboard or inside a desk drawer. Bruce Schneier, in contrast (and as usual) takes a far more intelligent attitude to changing passwords. For example, he concludes his thoughtful review of the question with the following well-reasoned advice:

“So in general: you don’t need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you’ve shared a computer with, change them all.”

What a contrast with “You must change your password every 30 days and that’s all there is to it.” The discussion at the end of the article includes many thoughtful postings from readers, most of whom seem to me would agree with the principle that “reality trumps theory.”

IA is a balancing act: we must constantly weigh benefits against costs – and I’m not just talking about direct financial costs. Despite our heartfelt yearning for quantitative risk management, we are stymied by the lack of an adequate statistical base for annualized loss expectancies (ALE). We have neither accurate frequency data for specific problems nor accurate data about monetary losses. As I have explained for decades, information security breaches suffer from the problem of ascertainment (we may not notice a breach at all or not for long time) and the problem of reporting (we have no centralized data collection facility and victims may choose not to report breaches and costs to anyone). Using best practices and formal standards make sense, but no set of prescriptions can be applied as if we were following a recipe.

One of the resources in security-policy development I have used since the 1980s is the evolving series, “Information Security Policies Made Easy” by Charles Cresson Wood (ISPME). Now in its 12th edition, ISPME consistently emphasizes importance of adapting the recommended policies to the specific needs of the customer. I opened my copy of the 10th edition at random and immediately found the following example of Wood’s emphasis on thoughtful application of policy rather than dogmatic rigidity:

2. Performance Evaluations

Policy: Compliance with information security policies and procedures must be considered in all employee performance evaluations.

Commentary: This policy requires management, at the time they write performance evaluations, to decide whether the involved employee has been be concerned about information security, and if the answer is yes, then to determine whether the employee has acted in compliance with policies and procedures. The policy provided here makes direct reference to the management activity of evaluating employees, and only indirectly to a rank-and-file employee activity of complying with policies and procedures. Nonetheless, it implies that both are expected by management. The words “information security policies and procedures” could be changed to “information security requirements” or other generic terms used at the organization.

Related Policies: “Information Security Responsibility” and “Information Security Liaisons.”

Audience: Management

Security Environments: All

In my career, I have been saddened to see IA being damaged by authoritarians who refuse to discuss policies with concerned users. These people act as if their primary goal is enforcement of their initial conception of appropriate security, impervious to warnings that their initial conception is wrong and uninterested in changing circumstances that render their absolute rulings ineffective by any standard. These autocrats enrage their customers – and yes, I always use the concept that information technology and information assurance should consider the user community their customers – and result in widespread contravention of their inappropriate policies.

In closing, I want to remind readers that one of the most effective tools for establishing well-received security policies is to explain the reasons behind every policy. Charles Cresson Wood has used this technique throughout his work, as exemplified in the commentaries for every suggestive policy in his magisterial text. When I ran my own consulting firm, the company’s motto was “Progress Toward Autonomy” and I required every contract to include a specific person with whom I could discuss every step of the performance optimization, operations management restructuring, or security assessment for which I was being paid. In my teaching, every recommendation, every principle is explained, not dictated; I constantly urge my students not to memorize, but to integrate knowledge.

Life is not a computer game with rigid and predictable rules; life is a multidimensional manifold that changes all the time.

Reality trumps theory.

In a recent discussion in the Norwich University IS342 (Management of Information Assurance) course in the Bachelor of Science in Computer Security and Information Assurance, the class reviewed Rebecca Gurley Bace’s chapter 46, “Vulnerability Assessment” from the Computer Security Handbook, 5^th Edition.

Bace explains that vulnerability management includes several phases:

• Assessing deployed information systems to determine their security status;
• Determining corrective measures
• Managing the appropriate application of the corrections.

The four basic functions of vulnerability management are

• Inventory: identify all systems in the domain of interest, including operating systems, platforms, and topology;
• Focus: determine the data required for assessment and tune vulnerability-assessment tools;
• Assess: run automated and manual tests, evaluate results to judge risk to the systems using security policy and best practices;
• Respond: execute changes as required by assessment and fix specific weaknesses.

Vulnerability assessment (VA) involves gathering sample data, organizing the data, comparing the current status with reference standards, and identifying discrepancies between the current state and recommended standards or goals. An example of a well-known VA tool is the Microsoft Baseline Security Analyzer v2.2 (MBSA) that “provides a streamlined method to identify missing security updates and common security misconfigurations.” The product has been updated over the years to support Windows 7 (32- and 64-bit) and Windows Server 2008 R2 as well as older operating systems back to Windows XP and Windows 2000. It also looks for documented weaknesses in “all versions of… Internet Information Server (IIS) 5.0, 6.0 and 6.1, SQL Server 2000 and 2005, Internet Explorer (IE) 5.01 and later, and Office 2000, 2002 and 2003 only.” Versions of the human interface are available in German, French, and Japanese in addition to English.

For an excellent overview of how a well-design VA tool can support security management, see the extensive set of white papers from StillSecure about their “VAM” product.

VA fits into security management in many ways:

• When systems are first deployed, VA can establish a baseline definition of the security state;
• When security breaches are suspected, VA users can focus on likely attack paths;
• VA may help administrators to see if vulnerabilities have been exploited;
• VA can identify areas where newly reported vulnerabilities should be patched;
• Records of VA scans can be archived and serve for audits or for compliance with certifications.

At a fundamental level, VA systems support auditability, which in turn supports incident handling and recovery. VA is an essential part of continuous process improvement for security policies to adapt to the constantly changing threat-and-vulnerability environment.

History and Directory of VA Tools

One of the earliest VA tools was COPS (Computer Oracle and Password System) developed by Eugene “Spaf” Spafford and Dan Farmer at Purdue University.

In the early 1990s, the Internet Security Scanner (ISS) was the subject of a Computer Emergency Response Team Coordination Center (CERT-CC) Advisory warning of “software that allows automated scanning of TCP/IP networked computers for security vulnerabilities.”

Dan Farmer & Wietse Venema developed SATAN (Security Administrator Tool for Analyzing Networks) in the early 1990s and posted the code in 1995. For an overview of the tool, see the page at the Center for Education and Research in Information Assurance and Security (CERIAS).

NESSUS from TENABLE Network Security is described by the company as “the world’s most widely-deployed vulnerability and configuration assessment product with more than five million downloads to date.” The product is freely available for individual, non-commercial use and has an evaluation version for use by organizations. The evaluation page includes a chart comparing features of the evaluation version and the professional version, which at the time of this writing (April 2012) costs U$1,500 per year.

NMAP (NetMAPper) is a widely used freeware “for Linux, Windows, and Mac OS X.” The home page boasts that “Nmap was named “Security Product of the Year” by Linux Journal, Info World, LinuxQuestions.Org, and Codetalker Digest. It was even featured in eight movies, including The Matrix Reloaded, Die Hard 4, and The Bourne Ultimatum.” [Perhaps other products should consider demonstrating their quality by appearing in popular movies. Imagine how popular MS Word could become if it appeared in Monty Python movies!]

One of the most useful tools for individual users as well as for network administrators is Steve Gibson’s ShieldsUP! service which provides a quick scan of the first 1056 ports of an individual computer. Ideally, every port will register as “Stealth” (not responding to probes) or at least as “Closed” (not accepting connections).

For links to more products, see the excellent “Alphabetical List of Vulnerability Assessment Products” maintained by Timeberline Technologies.

Concluding Remarks

One of the most important suggestions for effective penetration testing (pen testing) is that vulnerability analysis and vulnerability remediation must precede testing. It’s pointless to waste time and money on pen testing if we haven’t corrected everything we can find using scanners.

* * *

For study notes on vulnerability assessment, download the IS342 PPTX or PDF files.

In a landmark series of tests at the Department of Defense, the Defense Information Systems Agency found that very few of the penetrations it engineered against unclassified systems within the DoD seem to have been detected by system managers. These studies were carried out from 1994 through 1996 and attacked 68,000 systems. About two-thirds of the attacks succeeded; however, only 4% of these attacks were detected…. [O]f the few penetrations detected, only a fraction of 1% were reported to appropriate authorities.

One interpretation at the time was that if the US military was incapable of convincing its professionals to notice and report more than a tiny fraction of the minority of penetrations that were even noticed, the chances were low that non-military branches of the government, private industry, and other non-governmental organizations were doing even that badly.

One of the reports on this project is in the “Security in Cyberspace” document presented to the Permanent Subcommittee on Investigations of the Committee on Governmental Affairs of the United States Senate for the 104th Congress, on May 22, June 5, 25 July & July 16, 1996. Several formats of the report are available online including the 29MB PDF version. There is a reference to the 65% successful penetration rate on page 37 of that document.

US Government Projects

There has been progress in information sharing about computer crime. For example, the Common Vulnerabilities and Exposures (CVE) Database run for the US government’s Computer Emergency Readiness Team of the National Cyber Security Division in the Department of Homeland Security(DHS) by MITRE Corporation has been widely adopted by organizations around the world as a repository of shared definitions and descriptions of what it defines as follows: “An information security ‘vulnerability’ is a mistake in software that can be directly used by a hacker to gain access to a system or network.” These definitions provide a basis for information sharing by standardizing terminology so that different software systems and databases can share data using the same nomenclature. Even if internal names used within the different products don’t match, tables of equivalence of the local names with CVE entries can still allow communications.

To search the CVE, use the National Vulnerability Database maintained by the National Institute of Standards and Technology (NIST). At the time of writing (mid-March 2012) there were 49,627 records in the database.

Another constructive US government contribution to security-information sharing is the “Information Sharing Strategy for the Department of Homeland Security” (ISS) of 2008. The DHS summarized the strategy as follows:

The President and Congress have directed the DHS to perform an essential and multi-faceted mission: prevent and protect against terrorist attacks; respond to both man-made and natural disasters; perform the law enforcement and other crucial functions of the Department’s component agencies; and play a central role in augmenting the Nation’s ability to gather, analyze and disseminate information and intelligence.

To ensure that information and intelligence flow where and when they should, DHS must foster information sharing, consistent with law, regulation and policy, in each of the following ways: i) internally within DHS, ii) horizontally within the U.S. government between both law enforcement agencies and the intelligence community, iii) vertically with State, local, territorial, tribal and private sector partners, and iv) horizontally with the law enforcement and intelligence agencies of foreign allies and appropriate international institutions.

The ISS established Information Sharing Standards described as follows (summarizing p.7):

• Functionality in the critical infrastructure is primary, not technological details;
• Information sharing will maximize interoperability regardless of technical infrastructure;
• Readily-available commercial standards and protocols will be the standard for information interchange;
• Information sharing will respect privacy and security of the shared data.

The overview page for information-sharing projects run by DHS includes details and links for three computer-related services among the nine listed:

• Automated Critical Asset Management System (ACAMS)
• CIKR Asset Protection Technical Assistance Program (CAPTAP)
• Protected Critical Infrastructure Information (PCII) Program

UK & EC Programs

In the United Kingdom (UK), plans released in November 2011 for a UK cyber-security and cyber-crime strategy include a special unit with the National Crime Agency. Writing for eWeek, Fahmida Y. Rashid added that

The plan outlined a new public-private sector collaboration in which the government and businesses will exchange information on cyber-threats and responses…. [T]he partnership will allow organizations to receive classified details about cyber-attacks and information on how to counter them.”

Rashid writes that the definition of national infrastructure will be expanded to include more of the private sector, and the public will have a centralized system for reporting cybercrimes and receiving technical advice on appropriate responses.

At the European Community (EC) level, a report by Tom Espiner in ZDNet discussed a report by the European Network and Information Security Agency (ENISA) that failure to share information about cyber-incidents among national computer emergency response teams (CERTs) is reducing the effectiveness of the organizations. ENISA published its report in English and also a summary of the survey that was used in preparing the full report. The report describes and evaluates 30 different “Services for the proactive detection of network security incidents” (p 27 ff using the page numbers in the document, not the PDF page numbers) and 12 “Tools/mechanisms for the proactive detection of network security incidents” (p75 ff). The report continues with detailed analysis of “shortcomings in the proactive detection of incidents” (p 108 ff) and ends with several pages of recommendations (p 128 ff) for both data providers and for data consumers. The conclusions (p 133) end with the assertion about the importance of data sharing: “The end goal is improving data sharing and cooperation in proactive detection and incident handling between CERTs – an essential element for the successful mitigation of cyber-attacks.”

Private Sector

Internationally, organizations such as SANS do their best to share security information using “Consensus Research Projects” which currently include the following three relevant titles:

• 20 Critical Security Controls
• Top Cyber Security Risks
• Top 25 Software Errors

Among the countless research scientists constantly publishing valuable insights into systemic and specific errors in security and recommending practical improvements, Peter G. Neumann, Principal Scientist for the SRI International Computer Science Laboratory is one of the stars of the academic firmament. He has been moderating the “Forum on Risks to the Public in Computers and Related Systems” (usually just called the Risks Digest) continuously, brilliantly and amusingly (he is an inveterate punster) since 1985. As a contribution to ease of access, I have compiled PDF files for each volume from 1 to 25 (1985-2010) and will be adding the next volumes within a few months of this writing. Readers may also download a single ZIP archive file with all the PDF files for volumes 1 to 25 and another ZIP archive with PDF index (PDX) files for rapid local lookup.

Concluding Remarks

I want to finish with a few personal comments about how I see the international implications of data sharing to fight cyberattacks and rectify vulnerabilities.

Criminals and terrorists worldwide now have the power to engage in asymmetric warfare against the critical infrastructure of nation-states. A few people can create and control botnets involving thousands of compromised systems that can spread malware and launch distributed denial-of-service attacks that can impede access to or even crash targeted production systems. Tailored malware such as Stuxnet can target specific models and brands of supervisory control and data acquisition (SCADA) systems. Volunteer hacktivists can reveal vast volumes of classified materials, with unpredictable effects on public reaction, government policy, and international diplomacy. Such electronic gangs may even be out-stealing cybercriminals. And state-sponsored actors could easily carry out attacks on a particular target using IP-spoofing to divert attention from their country to some other target in the hope of provoking international conflict.

As the reliance on information systems in critical infrastructure has increased over the last several decades, the need for information sharing has grown not only to increase technical resistance to failures and to attacks: information sharing has become essential to prevent international conflicts based on the behaviour of non-state actors, on misunderstandings, and on deliberate sabotage and misrepresentation. Effective information sharing, especially between and among potential adversaries, may be a tool for increasing cooperation and reducing hostility on the international stage.

At a courthouse in Austria, on 28 February 2012, a security-training exercise went wrong.

In the weeks running up to the events of 28 February, police forces and the courthouse management were involved in planning what they believed to be a bright idea: conducting an exercise for courthouse staff on how to respond to someone running amok within the building.

Such an incident had happened only a couple of months before at a different courthouse in a different state in Austria, leaving two people dead (including the perpetrator) and a number of staff severely traumatized.

Training for such an event, by itself, was therefore not a bad idea, although such events are extremely rare in Austria (this was second such incident in about 50 years).

The exercise was executed on 28 February by police forces and conducted in an extremely realistic way. Realistic indeed: it included one simulated death, apparently by a gunshot to the head. Makeup was used to simulate injuries, and several officers were placed in the building as if they were injured persons. The supposed death was staged in front of courthouse staff who were evacuating offices.

There was one catch, though: the exercise was entirely unannounced to staff and no preparations whatsoever were taken to prepare staff for the experience.

The effect of this omission was devastating. By the next day 40 staff members were in treatment for severe trauma and an undisclosed number had taken sick leave. We must assume that some will suffer from post-traumatic stress disorder (PTSD) in the weeks and months to come.

In a TV interview, a courthouse spokesperson justified actions by stating that the exercise was unannounced because “…[I]t is our experience that announced exercises are not taken seriously by staff.”Although this assertion may be true, it does not justify exposing staff to a potentially traumatizing experience, especially given that if people cannot determine if a situation is staged or real, they must assume that it is real.

As this is being written (mid-March 2012), the latest news about the botched training exercise is that affected staff members still receive treatment and the next in line superior court to the one affected has publicly apologized for the exercise.

For all of us planning awareness and training, it is essential to remember that surprising, frightening, embarrassing and humiliating our colleagues will not help improve security. There is no point in going through the expense of simulations and tests if we have not prepared our teams effectively and resolved everything that can be resolved before the exercises. Having unprepared staff members also means that no one is monitoring events dispassionately – or with video footage – for an effective post-training discussion of what can be improved. Exercises are supposed to contribute to continuous process improvement, not nightmares.

We finish with sound advice from noted security expert and author Rebecca Gurley Bace wrote in her chapter (#46) of vulnerability assessment (VA) in the Computer Security Handbook, 5^th Edition,

Given the relatively unconstrained spirit associated with penetration testing, it is critical that the process be managed properly. Some of the requisite management considerations mirror those of the more generic process of [vulnerability assessment (VA)]. Independent oversight is required for the conduct of VA; it is especially critical to the success of penetration testing. Test scenarios should be documented and approved in advance by at least two representatives of the organization being tested, and the employees of the organization should be prepared for testing, especially when social engineering techniques are included in the scope of penetration testing.

This set of agreements and preparation for testing is key to balancing the need to perform realistic and relevant VA (including penetration testing) with the need to minimize the impact of such testing on normal business operations.

As human systems and constructs are as much a part of business operations as information systems, minimizing impact involves consideration of the ethics of social engineering. The first ethical tenet asserts that social engineering tests should not cause psychological distress to test subjects. Most employees are conscientious with regard to security and other company policies and may consider being targeted by social engineering tests as a breach of trust. Their reactions to that perceived breach may range from anger to resignation, or to a lawsuit.

Another ethical tenet states that those who fail social engineering or other penetration tests should not be subject to humiliation; this requires that test results be treated as confidential information. Finally, testers should not rely unduly on verbal misrepresentation or acting to achieve the goals of testing—the objective of such testing is to establish whether security measures are appropriate and effective for the organization, not to score a win for the test team at all costs. To leave a tested organization in worse condition than the test team found it is a hollow victory for all involved.

So forget dreams of Hollywood special effects and a compelling theatre experience: involve employees in all preparations for exercises, drills, simulations and tests.

* * *

Michael Krausz studied physics, computer science and law in university. He is a professional investigator as well as lead auditor for ISO27001 compliance. He designed the first ever information security training classes in Austria (1998) and has assisted in setting up certifying bodies and accreditation authorities for ISO27001/ISO27006. Having worked in 14 countries so far on a range of information security topics, Mr. Krausz has published two English-language books on managing information security breaches [Information Security Breaches: Avoidance and Treatment Based on ISO27001 & Managing Information Security Breaches]. He has recently published a German-language book on the dangers and challenges the Internet for the individual and the state in collaboration with the head of the Cybercrime Unit at the Austrian Federal Criminal Intelligence Agency, Mr. Leo Löschl [Schauplatz Cyberworld ]. Mr. Krausz is a national member of ISO’s JTC1/SC27/WG1 committee and editor of ASIS’s investigation council’s newsletter.

Advanced Persistent Threat (APT) has received a great deal of attention in recent months[1] due, in large part, to a spate of highly-publicized successful attacks against the information assets of major enterprises and corporations. Much of the recent focus on APT has come as a result of the RSA breach,[2] believed to be an APT-style attack[3], which led directly to a handful of serious attacks “down-line” within several of RSA’s major enterprise customers.[4]

Defining APTs

APT is, fundamentally, a specific class of attack(s) against enterprise information assets. It is a sustained, goal-oriented, and typically well-funded method of attack deployed for the purposes of committing espionage, confidentiality breaching, and overall disruption of standard business operations.[5, 6]

APT attacks originate from inside a security perimeter, usually initiated through an e-mail (spear-phishing) combined with a cross-site scripting (XSS) or cross-site request forgery (CSRF) attack, and proceed throughout an enterprise seeking to exploit errors and vulnerabilities in applications, servers, or network architectures. These are hard to detect because they look like normal traffic. They are characterized by a patient methodical approach, starting from beachheads consisting of hosts inside targeted networks. Once a host has been compromised, the attacker can usually hijack the privileges of the host’s user(s). The objectives are two-fold:

1)      Exfiltrate sensitive information gleaned by accessing enterprise applications with escalated privileges;

2)      Establish a latent ability to destabilize critical applications at some future time.

Fighting APTs

Most approaches to firewalling (selective blocking and/or modification of traffic at the network level) are aimed at detecting and blocking unauthorized traffic. The strategy for APT firewalling is necessarily different, however, because it aims to detect threats that use legitimate traffic.

The current approach is to detect a breach and shut down compromised endpoints or inhibit the foot-printing and attack activities against the applications themselves.[7] Remediation through endpoint clean-up is favoured by most of the relatively few organizations that are seriously addressing this problem because it’s simple and straightforward; periodic sweeps of the endpoints in a network seek to identify computers in which critical system files have been modified or rogue processes are running and, if found, these hosts are taken offline and rebuilt or replaced.[8]

Although straightforward, this approach is fundamentally reactive; it relies on static analysis, and operates out of band.[9] A better approach is to combine endpoint analysis with a proactive approach that can detect APT behaviour in real time and selectively report, obfuscate, or even block the behaviour.

Layer 3 Inadequate

Standard protection techniques like Layer-3 packet filters,[10] deep-packet-inspection firewalls,[11] and IDS systems running out-of-band on tap/SPAN ports[12] have their place. The problem, however, is that they’re of limited value in providing information assurance and the current generation of Web application firewall (WAF) products does not address this weakness. (There is no reliable study that we can find that has determined WAF market share and who the top three vendors currently are in that context.) Lacking fine-grained policy-enforcement capabilities and application-behaviour profiling, this product category can focus only on protecting internet-facing HTTP/S applications from non-application-specific attack vectors such as the Open Web Application Security Project (OWASP[13]) Top Ten vulnerabilities[14]. They are designed for inline deployment in demilitarized zones (DMZs) at the network edge, rather than for direct integration into the network core.

Applications Must Be Protected at the ApplicationLayer

Bayshore Networks has determined that directly increasing the resistance of applications to threats in the network infrastructure is the solution; vulnerability scanning and source-code audits, with remediation at the source-code level, are not sufficient[15, 16, 17] for enterprises with a large application portfolio, and are implausible for large enterprises. Among the problems:

1)      Sheer scale. Large enterprises have thousands of applications

2)      Heterogeneity. Some applications are commercial (most of those customized, sometimes drastically); many are ad hoc; some are open-source. Each one is essentially a unique development, and to remediate their errors and vulnerabilities in the face of constantly evolving threats is comparable to the complexity of writing and deploying the applications in the first place.

3)      Personnel: There is little, if any, access to the personnel who can work on commercial applications, and it is daunting at best trying to get the vendors to do it. With your in-house applications, not only have they probably never been audited, but far worse, the developers have long since moved on to other projects.

The bottom line is that enterprises that engage in the application-level remediation routes inevitably focus on a small handful of low-hanging fruit and declare victory.

Fingerprinting of applications[18] and exfiltration of data[19] from compromised hosts takes place constantly, and doesn’t depend on any given host’s remaining undetected. The standard tools for detecting compromised endpoints generally only run every few months (a single hour is enough to pull meaningful intelligence), and they usually only work on wired desktop PCs (not your smartphone or iPad), and can’t detect compromises that are clever enough to avoid changing the system files. This situation is unacceptable.

Attacks against application portfolios must be detected and remediated fast – in near-real time. And this speed depends, fundamentally, on determining variations from normal use to detect the presence of attacks. This is a very challenging and non-deterministic problem, which can only be solved using heuristic and statistical methods. Standard network firewalls, including next-generation firewalls, are not designed for this task.

Using our flagship product, SingleKey™,[20] we are successfully deploying a scalable way to harden a large application portfolio through an infrastructure-resident strategy, at the application layer, protecting all applications at once.

It’s critical to understand the objective here; successfully defending against APT requires the ability to automatically collect a detailed behavioural profile of each application, on each network link, in an on-going process. The dimensions of the profile must include specific data ranges that are allowable for each input to the application. With this profile in place, anomalous behaviours in each application can be detected immediately and selectively blocked or rewritten.

Secured networks must be architected with information assurance built in at a basic level, providing controls that are automatically available to all applications. These must be highly granular and application-specific, and it must be possible for operators and managers to easily escalate responses on a per-application basis. The control infrastructure must be able to block or modify application accesses that violate policy (requiring inline deployment), while not changing the user experience (requiring exceptionally high performance) or compromising operational availability (requiring a fail-open capability).

* * *

Francis Cianfrocca is Founder and CEO of Bayshore Networks, LLC which specializes in high-end IA products for a wide range of applications. Mr Cianfrocca is a noted expert in the fields of computer-language design, compiler implementation, network communications, and large-scale distributed application architectures. He has worked for a number of different companies either directly or as a consultant including Bank of New York, Gupta, McDonnell-Douglas and New York Life. A very strong advocate of open-source software development, he created several widely-used open projects, including the Ruby Net/LDAP library, and the EventMachine high-speed network-event management system. He is also a talented musician who attended the Eastman School of Music in the Music History department and studied for his Master’s Degree in Orchestral Conducting at the University of Michigan. Mr Cianfrocca is a member of the 2000 class of Henry Crown Fellows at the Aspen Institute

* * *

Copyright © 2012 Francis Cianfrocca & M. E. Kabay. All rights reserved.

Permission is hereby granted to InfoSec Reviews to post this article on the InfoSec Perception Web site in accordance with the terms of the Agreement in force between InfoSec Reviews and M. E. Kabay.

NOTES:

[1] Schwartz, M. J. (2011)

[2] Coviello, Jr, A. W. (2012)

[3] Chabrow, E. (2011)

[4] Krebs, B. (2012)

[5] Kimmel, C. (2011)

[6] Solutionary (2011)

[7] Ashford, W. (2012)

[8] Symantec (2010)

[9] Freedman, A. (2012)

[10] Freedman, A. (2012)

[11] Wack, J., K. Cutler & J. Pole (2002)

[12] Pappas, N. (2008)

[13] OWASP (2012)

[14] OWASP (2010)

[15] Ono, R. (2004)

[16] Roy, R. K. S (2009)

[17] Yamaguchi, F., F. FX Lindner, K. Rieck (2011)

[18] Shah, S. (2004)

[19] Giani, A., V. H. Berk & G. V. Cybenko (2006)

[20] Bayshore Networks (2012)

REFERENCES:

Ashford, W. (2012). “How to combat advanced persistent threats: APT strategies to protect your organization.” ComputerWeekly.com (no date). < http://www.computerweekly.com/feature/How-to-combat-advanced-persistent-threats-APT-strategies-to-protect-your-organisation >

Authentication.” Educause (2004-08-02). < http://net.educause.edu/ir/library/pdf/EPS249.pdf >

Bayshore Networks (2012). “SingleKey™ Information Assurance (IA) Firewall – Product Description.” < http://www.bayshorenetworks.com/singlekey-ia-firewall.php >

Chabrow, E. (2011). “Advanced Persistent Threat Definition Evolves.” Healthcare InfoSecurity – The Public Eye (2011-03-31). < http://www.healthcareinfosecurity.com/blogs.php?postID=918&rf=2011-04-01-eh&hq_e=el&hq_m=1028689&hq_l=14&hq_v=c6753f3f88 >

Coviello, Jr, A. W. (2012). “Open Letter to RSA Customers.” RSA (date unknown). < http://www.rsa.com/node.aspx?id=3872 >

Freedman, A. (2012). “Deep packet inspection.” Computer Desktop Encyclopedia (2012Q1). < http://www.computerlanguage.com/ >Via PC Magazine < http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3Ddeep+packet+inspection&i%3D58470%2C00.asp >

Freedman, A. (2012). “Out-of-band.” Computer Desktop Encyclopedia (2012Q1). < http://www.computerlanguage.com/ >Via PC Magazine < http://www.pcmag.com/encyclopedia_term/0,2542,t=out-of-band&i=48663,00.asp >

Giani, A., V. H. Berk & G. V. Cybenko (2006). “Data Exfiltration and Covert Channels.”

Kimmel, C. (2011). “A Perspective on Advanced Persistent Threat.” Infosec Island (2011-10-26). < http://www.infosecisland.com/blogview/17645-A-Perspective-on-Advanced-Persistent-Threat.html >

Krebs, B. (2012). “Who Else Was Hit by the RSA Attackers?” KrebsOnSecurity (2011-10-25). < http://krebsonsecurity.com/2011/10/who-else-was-hit-by-the-rsa-attackers/ >

Ono, R. (2004). “Effective Practice: Integrating Vulnerability Scanning with Web

OWASP (2010). “Top Ten Project.” The Open Web Application Security Project (2010-04-19). < https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project >

OWASP (2012). The Open Web Application Security Project. < https://www.owasp.org/index.php/Main_Page >

Pappas, N. (2008). “Network IDS & IPS Deployment Strategies.” GSEC Gold Certification, SANS Institute (2008-04-02). < http://www.sans.org/reading_room/whitepapers/detection/network-ids-ips-deployment-strategies_2143 >

Proceedings – SPIE Sensors, and Command, Control, Communication and Intelligence (C3I) Technologies for Homeland Security and Homeland Defense V. < http://www.ists.dartmouth.edu/library/293.pdf >

Roy, R. K. S (2009). “3 Reasons why Automated Vulnerability Scanning does not work.” The iViZ Blog (2009-12-21). < http://www.ivizsecurity.com/blog/penetration-testing/what-everybody-ought-to-know-about-free-vulnerability-scanning/ >

Schwartz, M. J. (2011). “6 Worst Data Breaches Of 2011.” InformationWeek Security (2011-12-28). < http://informationweek.com/news/security/attacks/232301079 >

Shah, S. (2004). “An Introduction to HTTP Fingerprinting.” Net-Square (2004-05-19). < http://net-square.com/httprint/httprint_paper.html >

Solutionary (2011). “Solutionary White Paper – Defending Against Advanced Persistent Threats.” < http://www.solutionary.com/index/intelligence-center/white-papers/apt-white-paper-reg/apt-white-paper-lp.php >

Symantec (2010). “Best practices for troubleshooting viruses on a network.” KB Article TECH122466 (2010-01-15). < http://www.symantec.com/docs/TECH122466 >

Wack, J., K. Cutler & J. Pole (2002). “Guidelines on Firewalls and Firewall Policy.” NIST Special Publication 800-41. < http://www.gmdit.com/Files/NIST_FirewallGuidelines.pdf >

Yamaguchi, F., F. FX Lindner, K. Rieck (2011). “Vulnerability Extrapolation: Assisted Discovery of Vulnerabilities Using Machine Learning.” WOOT’11 – Proceedings of the 5th USENIX conference on Offensive technologies – USENIX Association Berkeley, CA (2011-08-08:12).  < http://www.usenix.org/events/woot11/tech/final_files/Yamaguchi.pdf >

To start with, we face two fundamental problems in all discussions of crime, especially white-collar crime, and particularly computer crime: we have incomplete ascertainment and we have incomplete reporting.

The problem of ascertainment lies in the difficulty of identifying crimes or errors that compromise confidentiality and control, at least until the malefactors reveal the data leakage by using the purloined information. And unfortunately, we don’t yet have any centralized reporting of computer crimes or legal requirements for contributions to such a central database – so we lack reliable estimates of the frequency and severity of computer security breaches.

Nonetheless, a broad consensus among IA practitioners does support the belief that a sizable proportion of damage to computer systems may be from errors and omissions – perhaps even half. The attacks from the outside of systems and networks have increased over the last two decades because of the huge increase in interconnectivity due to wide use of the Internet.

Under these conditions, selecting appropriate employees can be a major contribution to effective IA. This review looks at hiring, management and firing from the perspective of IA managers.

Hiring

Everyone with access to organizational information must be trustworthy; furthermore, it makes sense to put extra care into the hiring process for all employees who will be supporting computer systems such as operators, technical support personnel, programmers, managers, and security officers.

A degree of background checking is appropriate, but must respect applicable laws against discrimination in hiring. With the permission of the candidate, one can look for criminal records, and credit records as well as verifying claims of educational attainment and professional experience. Don’t expect former employers to reveal much detail about the candidate beyond the dates of her employment; organizations are now highly sensitive to the risk of violating privacy laws or of stumbling into lawsuits for defamation.

In my experience as a technical services director for a sizable computer services company several decades ago, I found it particularly helpful to have candidates for a particular job be interviewed by the staff currently involved in that kind of work. The staff can gently probe the candidates’ bona fides with more detailed knowledge of the work that will be required than a manager who is a some remove from the day-to-day details of a job. They can also spot frauds more easily through their questioning; I remember one case where a poor fellow claimed to have three years of experience on the HP3000 (a “minicomputer”– think a big server) popular in the 1980s yet who could not log on to the system!

During the hiring process, successful candidates must be thoroughly briefed on corporate policies such as non-disclosure agreements for intellectual property, compliance with all regulations, and penalties for non-compliance. Some organizations have found it helpful to have a simple examination (usually automated) for the candidate to demonstrate knowledge of applicable policies.

Management

One of the key attributes of successful security officers is the ability to assume an attitude of paranoia. You don’t have to be paranoid: you just have to be able to act paranoid. Analysing how employees might abuse security systems and regulations is a constructive exercise in critical thinking. Security teams can benefit from exercises in thinking through how abuses could be carried out, how to respond, and how to improve processes to reduce risk. The organization should foster a belief in continuous process improvement, with suggestions for improvement welcomed, not criticized, and perhaps even rewarded. In one of my client sites, a factory, I remember seeing a poster that showed one of the employees with a big check – literally big: it was a couple of feet wide – made out for C$25,000. That amount (even more impressive than today in 1983) was 10% of the savings the employee had fostered in the first year through a suggestion for modifications in the production environment.

Another critical tool in training employees is how to respond to attempted collusion. An employee can practice dealing with such an uncomfortable situation in training sessions to get used to the idea that the first response should be to appear interested; the second is to report the attempted collusion to management so they can decide on appropriate actions (e.g., create a sting operation, record interactions with the criminal, and contact law enforcement).

One of the principles I teach is that access to computer systems or information is a privilege, not a right. It is unwise to grant access privileges to managers who don’t need it – there’s a risk that access will become a status symbol instead of a privilege tied to specific job requirements. One of the incidents that I recall with amusement occurred around 1985 when the president of the company I worked for brought a visitor from Toronto to our Montreal data centre on a Saturday night and asked the operator to let them into the computer operations room. The operator politely refused because the president was not on the list of approved unaccompanied visitors. The young man offered to call me for permission, but the president took the snub in good spirits. Indeed, he wrote a letter of commendation for the operator a couple of days later.

Another principle is “Kabay’s Law:” NO ONE SHALL BE THE SOLE REPOSITORY OF CRITICAL INFORMATION OR SKILLS. There was a horrible example of the consequences of violating this principle in a case I was involved in the mid-1990s. A network administrator for the three offices of a law firm was increasingly erratic in his behaviour – and we consultants had to meet offsite because there was reason to believe that he was reading all the e-mail of the executives! He was the only person who knew the root-access password, and he had never documented it in a way that his colleagues could have accessed. Dealing with an indispensable employee can be difficult. The norm must be that all operationally significant information must be documented; appropriate security for such documentation can include sealing passwords into opaque envelopes stored in the organization’s safe and accessible when two high-placed executives sign for it. Periodic testing of such repositories is appropriate.

On the procedural side, everything that affects the mission-critical operations of the organization must be part of the institutional knowledge of the group. At least two people should always be able to accomplish any given critical task; they don’t have to be perfect at it, but the disappearance of the prime should not put the organization in jeopardy.

Another guide for managers is to enforce vacations. There are two reasons for insisting on vacations. First, vacations offer an opportunity for live testing of the principles of operational resilience described above. Second, vacations offer an opportunity to see if someone has been carrying out secret operations that must be continued to avoid discovery. For example, if an accountant has been embezzling money by paying fake companies for non-existent services or goods (and using the fake bank accounts for his own benefit), a two-week absence may reveal the crime when another employee notices the fake entries and investigates what they were supposedly for.

If employees change their interpersonal style radically – whether for good or ill – supervisors might want to look into the situation. Becoming friendly (or angry, or depressed) does not mean necessarily that an employee is involved in anything bad, but managers will do well to investigate. I remember one astounding case where a modestly paid employee showed up at work with an expensive new car and claimed he had won a lottery. However, there was no public record of his winning anything – but investigation of his work showed that we was involved in taking bribes for relaying sensitive information.

The principle of separation of duties means that no critical operation should be completed by a single person. In the embezzlement scenario, it was a problem that the accountant was able to create invoices, approve them, and pay them without supervision.

Another warning for employers is that security policies must absolutely forbid unauthorized security testing. There have been many cases in which well-meaning employees have been fired for foolishly testing system security without informing anyone in advance and obtaining written authorization by a suitable manager. And on the converse side, claiming good intentions for security probes may be a cover for nefarious plans.

Termination of Employment

Well, things haven’t gone as well as they should. One or more employees must be fired for reasons such as workforce reductions, mergers and acquisitions, or inadequate individual performance. The basic rule is that absolutely everyone must be treated with the same procedure and the same respect, regardless of manager’s emotions about the termination. If Albert is frog-marched to the exit by a security guard whereas Betty is treated to a joyful party, the message is clear: Albert is bad and Betty is good. Such implicit criticism and praise can lead to lawsuits for defamation (by the Alberts). It is best to maintain strict even-handedness when firing people; then the employees can organize a farewell party privately, on their own time, off the organization’s premises.

What about resignations? What is old Charlie has worked diligently for 30 years and is beloved by all? Can’t we have a farewell party on the organization’s premises? Well, it’s a pity, but in a litigious environment, it’s best to have the party off premises. Now, Charlie probably let people know about his pending resignation months or years before the event (for example, I have already told my Dean to expect my resignation at the end of May 2025), so there is no need for any surprise in how he is treated. Furthermore, it may be valuable for Charlie to help document details of his work that may not have made it into institutional knowledge and to train his replacements. Nonetheless, exactly the same process as for anyone else would apply to Charlie on the last day of work – the exit interview, clearing the desk, returning identification cards, and returning other corporate property.

An exit interview can be either a painful exercise or a positive experience. If the separation is amicable, the departing employee may be able to contribute insights that might have been more difficult to impart to managers while she was employed. Even if there is some friction underlying the departure, it’s still possible to extract useful information from the employee if she is willing to speak her mind.

Finally, the termination process must be tightly coordinated between the human resources group and the information technology and IA group. As the exit interview is underway, the employee’s access privileges must all be revoked and assigned to appropriate replacement personnel who will take up the tasks of their former colleague.

For a more detailed version of these points, you can see Chapter 45, “Employment Practices & Policies” by myself and Bridgett Robertson in the Computer Security Handbook, 5^th edition. For a PowerPoint presentation on the subject, you can freely download a PPTX file or a PDF version of the lecture notes.