We Don’t Need No Education

David here again. Chris Hoff, in his often imitated but never duplicated way, recently reopened the massive can of worms that is security awareness training. Go ahead and read the comments on both posts — they are energizing to say the least. I’ve included a paper that I wrote for our customers below. Given the original audience, it’s on the more formal side. Let me know what you think…. Contrary to popular belief, Security Awareness Training need not be a necessary evil, but can instead be an effective method of communicating with and training employees. This research note will outline both the need for, and scope of, an effective security training program. Few, if any, technology professionals have ever overestimated the ability of users[1]. Others claim that user security training is useless and a waste of time and money[2,3], saying that users are plenty smart but “They shouldn’t have to worry about it. This is a technology problem.” This viewpoint is all well and good as long as the scope is limited to technological issues such as viruses, spam, and phishing attacks. The problem is that the scope and scale of user education need to be much larger for effectiveness. Like any other tool, training is not the end-all and be-all of security. It needs to be used along with sound business process design[4], solid technical controls, and strong support from the senior executive team. In an enterprise environment, user security training is not: Telling users not to open emails from people they’ve never heard of Telling users not to click on random links on web pages Telling users to patch their own systems Trying to make users change the way they interact with their tools is very challenging, and the very nature of viruses, phishing, and the like make it very challenging for users to correctly discern the difference between legitimate and hazardous emails and websites. So these are ideal problems for solving with technology. Awareness of the threats, however, is directly useful for users, as they are often the first people to notice issues and notify the helpdesk. Good security training focuses on broader problems that don’t lend themselves to pure technology solutions. Training can be broken down into two major categories, General and Group-Specific. General security training is appropriate for all employees regardless of their job role. Group-Specific security training focuses on particular skills that are relevant to only a portion of the company. Examples of General Security Training include: Education on policies and procedures Fire/Tornado Drills What to do in an emergency, e.g., how to get 911 (or equivalent); how to contact on-site security Locations of First Aid kits Who to contact if you believe you have identified a security threat or risk “If you see something, say something” Not faxing/emailing organizational charts, phone lists, or other protected corporate information offsite Rules for how to handle confidential information Travel safety tips General security training has the advantage of aligning with common-sense emergency preparedness and professional behavior. It is well-suited to mass communication channels, such as email, web-based training, newsletters and posters. Regularly reminding employees about what to do (and not to do), and how, is a cornerstone of a strong security posture. Educating users about policies and procedures is key for not only maintaining a smoothl-running operation, but is absolutely necessary from the standpoint of compliance liability mitigation. For instance, the Payment Card Industry (PCI) Data Security Standard section 12.6 specifically mandates a security awareness program[5], and although not explicitly part of either Sarbanes-Oxley or Graham-Leach-Bliley, many auditors look for awareness training programs. Regular reinforcement is particularly necessary in organizations with high turnover rates, particularly for call centers, help desks, contract or temporary staff. The need for training goes well beyond compliance requirements, however. The following examples further illustrate the importance of ensuring that everyone is aware of the appropriate information. Users are the first line of defense in the organization and they are most effective when they know what to do. Examples 2 through 6 all focus on what to do should something unfortunate happen, whether that is a minor injury, a major disaster, or anything in between. Examples 7 and 8 are about loss of confidential information and intellectual property. One financial institution discovered through an email content scanning tool that well over 99% of the time that a customer’s PII (Personal Identifiable Information) was sent offsite there was no malicious intent. These security breaches were from unintentional or accidental causes. Not realizing that recipients of the email were not inside the company, or that the file contained PII, were by far the two most common reasons that this sort of data was leaving the company. Example 9 is all about the safety of corporate personnel when traveling. This is particularly important if employees travel to parts of the world which are known to be dangerous. However, general travel safety tips can be useful to all staff when traveling. Basic reminders like not checking laptops, and use of safety pouches for extra cash and passports, can save both the employee and the company a great deal of money, time and heartache. Examples of Group-Specific Training include: Disaster recovery and business continuity planning/training for operations staff Design/architecture/coding training for the development organization Fraud detection training for finance staff Group-Specific training tends to be in-depth and should be treated like any other subject-focused training. As such, it may include dedicated classroom time or attendance at conferences to bring teams up to speed in a timely fashion. One of the many definitions of security is the process of enabling a business to run in a risky environment. Thus a CSO needs to plan for the inevitable and the unthinkable. In a major disaster, a business continuity/recovery process can be the difference between staying in business and shutting down “for good”. In a high volume commerce or call center environment, the cost of even an hour of downtime can be extremely high. Having a plan is not sufficient.

Read Post

Curphey on BPM

Today, Mark Curphey posted about Tenets of Effective BPM. He lays out five high level principles for doing business process management. This is really great stuff. It’s so good, in fact, that I’m going to quote a huge chunk of his post here: 1. Understand and Documenting the Process Effect: Implement a Structured and Effective Information Security Program 2. Understand Metrics and Objectives Effect: Understand Success Criteria and Track Effectiveness 3. Model and Automate Process Effect: Improve Efficiency and Reduce Cost 4. Understand Operations and Implement Controls Effect: Improve Efficiency and Reduce Cost Effect: Fast and Accurate Compliance and Audit Data (Visibility) 5. Optimise and Improvement Effect: Do More With Less Effect: Reduce Cost Notice that none of the above is specific to security, but if you apply them you do get security and compliance benefits. Also, you recover cash for use with other projects without having to ask for more cash, which always makes you more popular with the CIO and CFO. Perhaps most importantly, this type of behavior enables you to demonstrate that IT Security is taking on a business oriented focus, which is good for your career and for raising the exposure of InfoSec at the executive level. It’s like the old maxim, dress for the job you want to have; you have to act like the executive you want to be treated as. Share:

Read Post

Leveraging Compliance For Security

One of the big issues facing companies these days is compliance – Sarbanes-Oxley, GLBA, PCI, and there will undoubtedly be more in the coming years. As a result, vendors are pushing all sorts of products that purport to help solve the compliance problem. However, compliance is not a technology problem – it’s a business problem which needs a business solution. By instituting sustainable business processes that effectively leverage people and technology, enterprises will become not just more secure but also compliant with current and emerging regulations. Business processes tie together the people and technology that comprise a company’s operational environment. Roughly equivalent in function to ligaments and tendons in physical performance, poor business processes weaken a company’s fiscal performance. An ineffective sales tracking system, for example, will cause major problems in terms of production schedules, order fulfillment, and customer satisfaction. On the regulatory side, such an ineffective system will negatively impact a Sarbanes-Oxley (SOX) audit, since control of both quotes and orders is necessary to know and validate a company’s financial standing. Consistent, repeatable processes should be the goal of every company to ensure sustainability. They are also the cornerstone of many different compliance frameworks, including: SOX, the Payment Card Industry (PCI), ISO 17799/27001, Common Criteria (ISO/IEC 15408), and GLBA; not to mention other local and international standards. I’ve outlined three steps below for designing business processes that, when well executed, will not only improve a company’s operations, but will also ease the workload related to proving compliance. Those steps are: Separation of duties: Create a simple system of checks and balances, for example by investing expenditure approval authority and check writing authority in two different entities or individuals. A basic principle set out famously in the US Constitution, this is simple and reduces the opportunity for embezzlement, for inappropriate procurement awards, and even for stock manipulation. In a high-risk environment, a company may rotate duties to prevent collusion. For instance, the Federal Reserve Board requires authorization by individuals from at least three different groups to move gold from one vault to another; designated representatives from each of these groups are rotated regularly as well. Need to know: Limit access to critical information to those few people who have a true need to know. Establish a process for regular review of these access lists. Quarterly or semi-annual review is fairly standard for sensitive applications, augmented by additional reviews triggered when an employee changes job roles to ensure that privileges are not kept by default beyond their relevance to actual job requirements. In the case of access to all corporate financials, a few key executives and auditors should be sufficient. Regardless of the mandates of PCI, the most prudent course is to encrypt the numbers for all credit card information that is handled and to minimize the number of people who have the ability to decrypt the data. People who don’t have access to data can neither lose nor steal it. Scrutinize the use of credit card information to verify consistency with company privacy and confidentiality policies. Never use real credit card data for test systems. Monitoring tools can also help identify vulnerabilities in this access control system. This general principle aligns with auditing requirements for both SOX and PCI compliance. Change management: Establish the framework for change – and, ironically, business continuity – by fully describing the system that exists. Often perceived as tedious, with burdensome documentation requirements, change management is a key control mechanism for managing and securing financial systems. Auditors appreciate the value of solid change management practices; companies should appreciate spending less time and money on audits.An effective change management process is methodical and simple. Document all system configurations or implement an automated tool to discover system configurations and record them by date. Detail the steps required for user moves, adds, and changes, and establish an audit trail. Record proactive security events, such as patch applications and anti-virus (AV) updates. Assign to each process business owners who are responsible for maintaining and documenting the process. Record all changes manually or automatically. When anomalies are observed or something “breaks,” consult the change log for clues about the likely origin for the malfunction. The documentation serves the additional purposes of increasing uptime, improving reliability, and speeding mean time to recovery. It forms the basis for a business systems resiliency or disaster recovery plan, especially when enhanced by including key contact and license/registration information. For multi-owner processes, assign responsibility for prioritizing and approving changes to a change management committee or board. This board, especially on the applications side, should have the ability to understand the dynamics of conflicting business requirements (internal and external), regulatory requirements (external), and the risk potential inherent in changes requested from different groups. A review board with a holistic view of the system for which change is contemplated will be able to identify hazards, negotiate details, and explain and “market” prioritizations to their individual work groups. If a business process needs to be changed, change it. I have laid out three key elements to consider when designing a business process or when revamping a business process in response to new or existing compliance, security, or environmental needs. Those elements are separation of duties, need to know, and change management. The benefits are lower cost and more reliable operations, less time and money spent on audits, and greater peace of mind for the organization.Business drives changes in process. Technology may enable – or inhibit – change, but it does not drive change. Consistent communications must exist, however, between functional areas (e.g., information technology) and lines of business (e.g., product engineering or consumer loans). Such communication facilitates incremental adjustments in technology deployment that must be recorded in system configuration documents, process updates, and business continuity plans. The continuous realignment of IT and business practice is comparable to the quality movements in manufacturing processes. Technology reinforces and supports changes in process. Tools should not determine the nature of change, nor how change is implemented. Leverage the existing change management

Read Post

Mogull on the Injured Reserve

So somehow Rich has managed to hurt his shoulder. He swears that it happened while helping blind nuns cross the street in an ice storm, but I don’t believe it. As he mentioned on Friday, he’s having surgery this morning to have it fixed, so everyone think happy thoughts towards Phoenix. Since he’s going to be out of commission for a while, he’s asked me and a few others to jump in and post while he’s on the mend. If I’m lucky, he’ll even forget to change the password once he’s recovered and I’ll keep on posting. For those of you who don’t know me already, I’m the CSO-in-Residence for Echelon One, where I run the research and analysis program and before that I was the CISO at Siebel Systems. Best of luck to Rich and hopefully he’ll be back to posting before you know it. Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.