February 25th, 2008
I’ve already covered the importance of a good information security policy, the process of creating such a document and putting its provisions in place, and why so many policies are less than adequate. I’d like to focus next on an acceptable use policy, a policy that explains what users and system administrators are and are not allowed to do when they use an organization’s computing resources.
Acceptable use policies, for example, usually among other things require that use of an organization’s computing resources must be for official, business purposes only. Additionally, these policies generally do not allow users to share their passwords under any circumstances.
An acceptable use policy is a “breakout” policy, i.e., a lower-level policy that provides and explains more specific provisions that a mainstream information security policy does not cover because of its high-level nature. An acceptable use policy is essential for two primary reasons:
- By stating the computer use ground rules, it helps users know what is expected of them. Without knowing this, users are likely to engage in behaviors that can easily lead to disciplinary action or even termination of employment. Acceptable use policies thus in effect protect users as well as system administrators in computing-related matters. Consider the unfortunate case from the last decade, the case of Randall Schwartz, who was a system administrator at Nike. Schwartz attempted to crack passwords in Nike systems when he was no longer the administrator of these systems in an attempt to show that security in these systems had gotten worse.
The company at that point of time did not inform employees that this kind of activity was not allowed, yet when Nike management heard that Schwartz had engaged in this activity, it pressed charges against him. Schwartz was originally convicted on several felony counts, although his convictions were eventually overturned after an incredible amount of effort, financial expenditure, and suffering on Schwartz’s part. In hindsight, Nike should have had an acceptable use policy something to the effect that password cracking and penetration testing were forbidden without prior approval of management.
- A well-written, well-distributed acceptable use policy also helps protect organizations against unfair lawsuits filed by employees who have been disciplined or terminated on the grounds that they engaged in computer misuse.
If it can be shown in court that a user who suffered the consequences of computer misuse had been forewarned by relevant provisions in an acceptable use policy, the chances of that employee winning a lawsuit against the organization in which the individual has worked are normally substantially diminished. Having a suitable acceptable use policy is thus a critical part of the due care posture of an organization.
Although acceptable use policies are both desirable and essential, provisions in these policies can fall behind the times and can thus end up being unreasonable.
The best example is the provision that employees are to use organization computing resources exclusively for job-related reasons. As my good friend, Dave Stacy (now of Thrivent Corporation), pointed out in a paper a number of years ago, job conditions have changed radically over the last 15 - 20 years. One of the most significant differences is that presently employees, especially white collar employees, are expected to be on the job 60 - 70 hours or more every week. At the same time these employees are working relentlessly for their employers, changes in stock and commodity prices are occurring, mortgage rates are rising or falling, and so on.
Requiring employees to wait until they can go home and use their own computers to, say, buy or sell stocks or commodities is not really fair when employees must stay at the workplace as long as they do. Relaxing the “business use only” provision of an acceptable use policy is thus often appropriate.
~ : ~
February 22nd, 2008
Last night I got back from an extended business trip to both the UK and Germany. On trips such as these I am often so busy that I have little time to really do justice to most of the email that I receive.
This frequently results in my trying to pick out what appear to be the seven or eight most important messages, read them, and respond to them before I have to rush off to do something else; my recent trip was no exception. Today was the day of reckoning—I am still going through the email that came to both my High Tower and personal ISP accounts. As I sort through everything I have received, the fact that I am having to deal with an excessive amount of spam traffic once again became very apparent to me.
What is particularly irritating is the ineffectiveness of spam filters in spotting and deleting messages advertising watches and blue pills when they are so very obviously spam and nothing more.
Twenty years ago, Internet spam was almost non-existent. The Internet was originally intended to be used for other than commercial purposes. If someone sent messages marketing or promoting some kind of commercial cause, the sender often received a barrage of negative responses from disgruntled users. Studies of spam show that spam started to substantially increase in the early part of the current decade to the point that somewhere between 80 and 90 percent of traffic going through ISPs’ connections is now spam.
Spam has truly reached the point that it can be safely labeled as an epidemic. The toll is not trivial, either. ISPs are charged on the basis of their volume of traffic—spam runs up this cost considerably. I also suspect that users such as myself lose at least one hour or more of otherwise productive work time cleaning out their email queues of the volumes of spam that accumulate each week. When you multiply this amount of time by the number of computer users within an organization, the productivity loss figure can be alarming.
Spam is a strange problem from an information security perspective in that it does not really result in loss of confidentiality, loss of integrity, disruption of availability, inability to assure non-repudiation, inability to establish accountability, and so forth. Cyberattacks invariably represent attempts to exploit vulnerabilities, but this is not in general true of spam. The only facets of spam that are more or less related to information security are the fact that so many spammers falsify senders’ addresses and also the fact that spammers sometimes launch attacks in an attempt to take over machines that they use to spew spam. It is thus somewhat bizarre that information security functions within organizations are so often called upon to counter the spam problem.
Various anti-spam solutions, of which the classic “spam wall” designed to analyze incoming email and block messages that match criteria for junk mail, are the most widely used. Somewhat more visionary solutions provide mechanisms that trace email to the server from which it has been sent; a mismatch between the indicated and actual originating server results in incoming messages being dropped. Presently, however, more visionary solutions are not at all widely implemented, let alone agreed upon.
The Internet is in fact now more at the mercy of spammers than ever before. One of the greatest challenges, therefore, is to create, agree upon, and implement suitable anti-spam solutions before the problem becomes even greater—so great that the attractiveness and utility of the Internet to users and organizations is greatly diminished.
~ : ~
February 19th, 2008
The US Computer Emergency Readiness Team (US-CERT) recently made headlines when it advised users to disable ActiveX in their Internet Explorer (IE) browsers by changing IE’s Internet security setting to “high.” The impetus for US-CERT’s announcement was the discovery of several new ActiveX vulnerabilities in ActiveX plug-ins for Facebook and MySpace and Yahoo’s music services. To the best of my recollection, although various individuals have recommended disabling ActiveX, no major organization has previously made such a recommendation.
The recently discovered vulnerabilities were only a few of many in ActiveX that have been identified over the years; many allow malicious code that runs with SYSTEM privileges (the highest level of privileges in Windows systems) to be injected into Windows systems, thereby allowing perpetrators to take complete control of victim systems.
Vulnerabilities in ActiveX fall into two categories, implementation bugs and design weaknesses.
ActiveX implementation bugs such as the ones that have recently been discovered are common, yet ActiveX does not really deserve to be singled out from among other types of Executable Content Languages (XCLs) because of the sheer number of vulnerabilities in it.
Why? The answer is that many vulnerabilities have also been found in JavaScript, Visual Basic, and other XCLs, so many that focusing solely on ActiveX vulnerabilities really makes little sense.
The second type of ActiveX vulnerabilities is the result of a security design problem in ActiveX, namely that ActiveX lacks proactive security mechanisms. ActiveX security to a large extent depends on “authenticode,” a mechanism in which a digital certificate that verifies the identity of the author of the code is provided with each ActiveX implementation.
Authenticode thus makes it possible to trace the identity of malicious ActiveX code authors after Windows systems have been compromised, something that at best is a poor consolation. In contrast, other types of XCLs have at least some proactive security controls.
After considerable deliberation concerning this issue, I feel compelled to side with US-CERT’s position on ActiveX.
Given that so many of today’s cyberattacks are against Web browsers and also that this problem is if anything getting worse, users and organizations are going to have to adopt more stringent security measures if they are going to avoid falling prey to one or more of the myriads of types of malicious code that exist today.
Disabling ActiveX is clearly one of these measures to be strongly considered. At the same time, however, IE is by far the most prevalent type of Web browser used today, so Web site developers almost invariably make their sites IE-compatible. Not surprisingly, therefore, ActiveX is also a critical part of the functionality of many Web sites; without ActiveX, sound effects and animation often do not work.
Disabling ActiveX thus has a real downside. Other browsers such as Mozilla Firefox do not support ActiveX, so simply switching browsers is not really a viable solution if one wants to continue benefiting from ActiveX functionality, either.
Information security invariably requires balancing costs versus benefits. There is a definite cost involved with disabling ActiveX, but given the huge toll (financial cost, disruption, loss of reputation, and so on) of today’s ActiveX-related security incidents, disabling ActiveX appears to be the better alternative at this time.
Additionally, if a significant portion of the user community avoids using ActiveX, Microsoft will almost certainly get the message and react by substantially improving ActiveX security, just as this software giant has already done with Windows operating systems, the Internet Information Server (IIS), and other products that it makes.
~ : ~
February 14th, 2008
This blog entry picks up where my previous one ended. Many potential pitfalls in developing an information security policy exist, but even if information security professionals manage to avoid these pitfalls, other obstacles can prevent such a policy from being effective.
The reason is that developing a policy is only the first part of what ideally should be an entire cycle of policy-related activities. This cycle should include assessing requirements (particularly through communicating with senior-level management), writing the policy, obtaining feedback and making appropriate changes, getting senior management sign-off, distributing the policy, enforcing the policy, and periodically reviewing the policy and making appropriate changes. Of all the activities in this cycle, enforcing the policy is often the most challenging.
Enforcing any information security-related requirement is usually tricky, but enforcing policy is often particularly challenging.
Several potential approaches exist, the first of which is to rely on audit to do the enforcement. Audit, after all, usually wields a big stick, or at least a bigger stick than most other functions. One of the major problems with this approach, however, is that one must wait until audit is ready to conduct an audit that includes reviewing compliance with policy.
Relying on other functions such as human relations (HR) to help with compliance is another reasonable approach, but there are some major limitations with this approach, too. For one thing, HR’s scope in looking at the range of issues included in an information security policy is generally much narrower than that of the information security function.
The information security manager (ISM) can also take on the role of security compliance officer, and is often compelled to do so. Although the ISM is likely to understand the provisions of information security policy better than anyone else, assuming the role of policy enforcer is risky because of the potential for alienating others within the organization. If the ISM assumes this role, the best approach is to take a kinder, gentler approach in which the ISM tries to persuade those out of compliance to comply rather than to attempt to force them to do so.
Some information security policies are well enforced, whereas others are not (or at least are not enforced very well). What about un-enforced policies? Security luminary Marcus Ranum has recently gone on record as saying that an un-enforced policy is really no policy at all. To say that a number of information security professionals took umbrage to Marcus’ assertion is an understatement. These professionals point out that factors well beyond the control of ISMs often result in information security policy not being enforced—the fact that there is a policy at least means that some of the necessary work in assessing and communicating high-level requirements has been done.
Still, if information security policies are to be worthwhile, they need to be instrumental in achieving risk management goals. If they fall radically short of their purpose because they do not increase compliance with its requirements, their value must be questioned. To say this more diplomatically than Marcus did, any information security policy that is not enforced does not really do much if any good, no matter how well-written it is.
The bottom line is that writing an information security policy is only the beginning point. A good policy is one that reflects senior management’s expectations, is signed off by senior management, states high-level requirements, is clear and easy to read, well-distributed, and properly maintained and enforced over time.
~ : ~
February 12th, 2008
Information security policy is a high-level set of security-related requirements that set the ground rules for security within an organization.
A good policy should cover critical issues such as user responsibilities, ownership of information processing resources and information, baseline security, and so on. A good information security policy is one of the critical underpinnings of an effective security practice, yet not all security policies in today’s information security practices are up to par.
As the High Tower CISO, I’ve wrestled with the provisions of our security policy. I am not trying to criticize any of my predecessors at High Tower at all, but when I took over the lead security role, I found our information security policy to not be what was needed.
Someone had apparently ordered what might be described as a policies kit that covered a wide range of security-related issues. Each area in turn consisted of a myriad of policy statements, many of which appeared to apply to environments that were considerably different from High Tower’s. I suspect that if every employee were required to learn the many policy provisions and then were tested on them, the average score would not have been very high; the amount of content was simply overwhelming. Perhaps worse yet, critical issues such as data ownership were omitted altogether.
I found that I had to throw out everything that had been done before and start working on our policy from scratch.
The starting point for me was talking with the person who was our CEO at that time to learn of his expectations concerning information security.
I used the notes from our talk as well as my knowledge of what our company is trying to accomplish and how we are trying to achieve our goals to identify nine major areas that I felt would have to be addressed in High Tower’s security policy. Among these was the area of employee responsibilities concerning the use and care of computing resources. Another was ownership of company information and computer resources.
I am a firm believer that an information security policy needs to be a high-level document—one that provides guidance and direction to management, system and data owners, system and network administrators, and users without specifying to a “T” exactly what to do.
Standards and procedures, both of which should ultimately be derived from policy, are designed to provide more explicit direction. Besides, just as a country’s constitution should continue to be meaningful over time and as conditions change, a good security policy should stay relevant over time and despite changes such as technology and operational changes within an organization. I thus wrote the policy provisions for the nine major areas of the policy such that each was covered at a sufficiently high level that they would provide meaningful direction without mandating exactly what to do.
No security policy will work universally exactly as it is written. Special business and operational needs that arise from time-to-time will dictate that exceptions to certain policy provisions be granted. I thus ensured that provisions concerning how to apply for and also how to grant exceptions were also incorporated into the High Tower policy.
I also believe that a policy that is not worded clearly will not achieve the desired results. I thus attempted to write the policy provisions using simple wording, My sentences also tended to be short. I “bounced” several draft versions off of a variety of High Tower employees to determine whether the policy provisions were as understandable as I wanted them to be, using the feedback I obtained to make modifications throughout the document.
Finally, I met with the CEO of High Tower to go over the policy document as it was at the time and ensure that he agreed with the provisions therein.
After making several modifications that he wanted, I asked him to sign off on the policy. Once he did so, I ensured that the signed version was posted on our company’s Web site. After all, without unambiguous senior management backing, employees and others such as contractors are likely to pay attention to little if any information security-related guidance and requirements.
A security policy is invariably a living document. No matter how well written a policy document is, changes will be necessary over time. I thus review the policy provisions no less than once a year, proposing changes as they are needed. The CEO must sign off on any changes. The most recent change, for example, concerned the addition of special precautions required when sensitive and proprietary information is taken offsite.
Policy is critical in information security. Without a policy that is appropriate for an organization’s business and operations, that is not openly backed by senior management, and that is clearly and succinctly written, information security efforts are almost invariably marginalized by lack of direction and also by what effectively amounts to anarchy.
I’ve shared some of the things I’ve done to develop and maintain an effective security policy at High Tower in the hope that they may help others who are struggling with policy-related issues in their own security practices.
~ : ~
February 7th, 2008
The Capability Maturity Model (CMM) was originally intended to characterize processes involved in software development that affect the quality of the code that is produced. In a nutshell, the lowest CMM level (level 0) is called “nonexistent;” there is no awareness of the need for systematic development processes. At the highest level (level 5), development processes are optimized by being implemented, monitored and managed throughout an entire organization.
The Software Engineering Institute (SEI) validated this model by empirically showing the relationship between processes in real-world software development settings and quality metrics such as number of bugs per 1000 lines of code.
Not surprisingly, the CMM model is also widely applied to information security practices to the point that it has become a major basis for measuring the performance of an information security practice.
There is a certain intuitive goodness to the CMM model; as one goes to higher CMM levels, more processes that appear to systematically address risk are present.
At level 2, for example, processes are repeatable but intuitive; comprehension the nature of risk and the need for security is just starting to happen. At level 3, there are defined processes, as evidenced by an organization-wide security risk management policy and the emergence of security training and awareness.
The CMM model has been applied to information security practices for at least a decade. Internal and external assessments of information security practices often produce the finding that practices seldom reach the highest level or even level 4. I have often asked attendees of information security management courses that I teach what level they think best characterizes their own information security practice. Invariably, the most common answers are levels 2 and 3. Why? Several reasons stand out in my mind:
- Failure on the part of information security managers (ISMs) to truly understand the nature of the business(es) that they are supposed to defend, support and enable. — Without a genuine understanding of the business itself as well as the business processes involved, a large gap between senior management’s and the ISM’s expectations is likely to develop, something that almost always costs information security practices in terms of credibility, leverage, and resources needed to effectively manage risk.
- A general lack of knowledge regarding information security management. — Too often technically competent people are pushed into information security management with any kind of appropriate information security management knowledge and skills. Many lack even the most basic knowledge of security, let alone security management. The result is inevitable-”barking up the wrong tree” (or sometimes simply wallowing in indecision) when it comes to managing security risk correctly and efficiently.
- Obstacles imposed by senior management. — Senior management’s lack of knowledge concerning information security is one of the most formidable obstacles to the maturity of information security practices. Without suitable knowledge, senior management is unlikely to adequately support information security efforts in terms of elevating the ISM position to a suitable level within the organization, signing off on policies, standards and procedures, providing adequate resources, and more.
- Lack of oral communication and interpersonal skills on the part of ISMs. — Although many ISMs excel in oral communication and interpersonal skills, some do not. The people factor is essential in on-the-job success (not just in information security, but also in just about every job and task); communication and interpersonal skills are thus essential if ISMs are going to bring their practices to levels of greater maturity.
- Failure to set proper security goals for information security practices and to monitor and report progress. — Too often ISMs do not set appropriate goals for their information security programs, or it they do, they do not design and put in place processes for monitoring and communicating (e.g., to senior management) the degree to which goals are or are not being met.
- Failure to cooperate with and leverage other, similar functions within organizations. — Other functions within organizations such as physical security and audit have many common interests and goals with information security. Given that resources available to information security are almost invariably limited, cooperating closely with and leveraging these other functions in mitigating risk is the most logical course of action. Some ISMs neglect doing this, however.
There are additional reasons that information security practices do not achieve greater levels of CMM maturity. However, the ones I have presented are in my mind the most critical.
~ : ~
February 4th, 2008
One does not have to be around information security professionals very long before hearing the term “best practices.” In theory, “best practices” means the set of security practices that the best or elite information security programs adopt.
BS7799 (the content of which has been incorporated into ISO/IEC 27001) is according to a large proportion of information security professionals a “best practices” standard in that it prescribes exemplary measures used by the most effective security programs.
Although the term “best practices” is widely used, my enthusiasm for this term is not commensurate with its popularity for a number of reasons.
The first is that the term is extremely misleading from a statistical perspective. Although “best practices” may be determined by analyzing the nature and components of leading information security programs, if a large proportion of security programs were to follow “best practices” (as many have), these practices would (and to a large degree actually have) become “normal practices,” not “best practices.”
A statistical value that is originally well above the mean of a statistical distribution cannot remain in its original relative standing if numerous other values that are the same or similar are added to the distribution.
Second, I am nervous about how “best practices” were originally identified, namely by inviting “leading security professionals” to working sessions. Although these professionals deserve a huge amount of credit for their accomplishments, it appears to me that their results represent consensus among a certain circle of professionals rather than the output of empirically-grounded and methodologically sound work.
A good analogy would be a situation in which people who were considered very intelligent in certain circles got together and defined “high intelligence.” Intelligence tests, which have been developed empirically, provide a far more suitable way to define and measure intelligence.
I worry, too, that the term “best practices” raises red flags in the minds of senior management because of cost connotations. In business, whatever measures are “best” usually cost the most.
With the US (and the entire world, for that matter) on the brink of recession, cost cutting is foremost in senior managers’ minds. For this reason, when security professionals mention “best practices” in making their case for more resources for their security programs, I suspect that they have already lost.
Additionally, although the concept of “best practices” is potentially useful, the set of measures that effectively counter security-related risk will to some degree (and sometimes to a very large degree) vary from one organization to another.
For example, firewalls placed in external gateways may not be as suitable for an organization that needs a more open and collaborative computing environment than one that needs to minimize risk due to externally initiated break-ins and denial of service attacks. To universally prescribe external firewalls as “best practice” measures would not make much sense in the former organization because the security control measures in question would not have the kind of cost to benefit yield as in the latter organization.
Considering all the problems in connection with the use of the term “best practices,” I propose that alternative terms be used instead. As a start, “sound practices” or “widely accepted practices” both seem far less misleading than “best practices.”
~ : ~
