Pratum Blog

Information Security leader training employees about security awareness

If you work in the IT world or deal with information security on a regular basis, you’ll hear people talking about “security awareness training.” The term can be confusing because awareness and training are not the same thing. Generating awareness of something is distinctly different than the act of training. Awareness is about the learner receiving information from the teacher. Training is an active, engaged process in which the learner builds meaningful knowledge and skills that facilitate action.

To adequately train your team in cybersecurity, think of learning as a continuum. It starts with awareness, builds to training, and can evolve into education for those making a career out of information security. Building on concepts from the National Institute of Standards and Technology (NIST), this article highlights the IT Security Learning Continuum and covers both the differences and links among awareness, training and education.

NIST - Figure 2-1: The IT Security Learning Continuum
NIST's IT Learning Continuum

Security Awareness

Awareness refers to having knowledge of a situation or fact. According to NIST’s glossary of terms, “Awareness is not training. The purpose of awareness presentations is simply to focus attention on security. Awareness presentations are intended to allow individuals to recognize IT security concerns and respond accordingly.” Examples of awareness activities include anti-phishing posters placed in common areas; discussions of stronger passwords at staff meetings; or informational videos distributed via email.

It's critical to build your security training program on a strong foundation of awareness. The only way we can expect teams to innately understand existing risks, let alone react to them, is to give them guidance. That guidance begins on an employee's first day by including cybersecurity awareness as a required part of the initial onboarding process

For example, NIST uses the example of building an awareness session (or awareness materials you distribute) around virus protection. You can address the subject simply and briefly by describing what a virus is, what can happen if a virus infects a user’s system, what the user should do to protect the system, and what the user should do if a virus is discovered.

NIST’s guide to IT security training requirements (known as SP 800-16) describes a transition stage between awareness and training called Security Basics and Literacy. At this stage, users learn a core set of terms, topics, and concepts. During the literacy stage, information is not tied to specific tools or systems. Literacy delivers basic concepts so that users can move on to more robust training programs, and it prioritizes personal responsibility and behavioral change.

Security Training

NIST SP 800-16 defines training as the part of the continuum that “strives to produce relevant and needed security skills and competencies by practitioners of functional specialties other than IT security (e.g., management, systems design and development, acquisition, auditing).” The most significant difference between awareness and training is that awareness seeks to focus an individual’s attention on an issue or set of issues, while training seeks to teach skills that allow a person to perform a specific function.

Awareness is a basic necessity, but training is the difference maker when it comes to truly safeguarding an organization’s sensitive information. And delivering information security training one time per year is simply not enough. You should plan to spread awareness and training activities across the year to provide greater persistence. Because cyber threats are constantly changing, the awareness and training program must be agile enough to provide information regarding the latest threats.

Security Education

NIST SP 800-16 defines education as the realm of people seeking a career in security. NIST says, “The ‘Education’ level integrates all of the security skills and competencies of the various functional specialties into a common body of knowledge, adds a multidisciplinary study of concepts, issues, and principles (technological and social), and strives to produce IT security specialists and professionals capable of vision and pro-active response.” Education goes beyond basic security courses and training. In NIST’s view, education is accomplished through a degree program at a college, university, or other educational forum.

You don’t need to give everyone a formal security education to establish a successful security program. Awareness and training, however, are integral to a security-minded business culture.

Pratum’s team can help you create an awareness and training program tailored to your team’s specific needs. To get started on your program, contact us today.

Incident Response vs. Disaster Recovery vs. Business Continuity

In a world getting less predictable every week, good business leaders proactively prepare for cyber incidents with plans that anticipate and minimize disruptions. But as you start looking ahead, it’s easy to get confused about the differences between incident response plans, disaster recovery plans and business continuity plans. In this post, we’ll explain how the plans all weave together into a holistic strategy to protect your business.

Incident Response Plan

The IR plan is the overarching document that gives your team clear guidance on exactly what to do during incidents, data breaches, and other pressure-packed situations when it’s easy to get overwhelmed. If you realize you may be facing a cybersecurity incident, the IR plan will help direct your actions. Every good cybersecurity program puts a high priority on writing and regularly reviewing an IR plan. In many cases, you may be required to have one by industry regulators, your cyber insurance company, key customers who want assurance that you can handle incidents, etc.

Your IR plan will describe your specific:

  • Definition of an incident – A clear checklist helps your team recognize situations serious enough to set the IR plan in motion. The plan also should include criteria for identifying the next stage: an actual disaster that triggers the disaster recovery/business continuity (DR/BC) plan.
  • IR team structure with each person’s responsibilities – This list ensures you have the right voices in the room. It’s easy, for example, to include a lot of IT people and forget to include reps from HR, legal, PR, etc. Be sure to include an executive who can make things happen in a pinch. For each person, clearly describe what they’ll do during an incident.
  • Procedure for reporting incidents – The plan works only if the right people learn about the incident in a timely manner. Clearly explain how team members should report suspected incidents through the right chain of communication.
  • Guidelines for talking to outside parties – When do you tell your customers what happened? Who is allowed to talk to the media if they call? Your plan should anticipate those scenarios and describe what to do.
  • Structure for summarizing lessons learned – Create a method for debriefing the incident, clearly stating what happened and making adjustments as required.

Disaster Recovery

Note that many organizations combine the DR and BC plans into a single document that outlines the processes involved for declaring a disaster, the formulation of the Response Team Members, the processes necessary for a secure recovery, and finally the steps necessary to maintain the continuity of business operations. We’ll explain the differences in the documents here, but rather than fixating on rigid definitions, just make sure you have thorough plans in place.

The DR plan usually centers specifically on data and technology operations with processes for recovering information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. The DR plan explains, for example, how you can restore lost data, whether that means restoring a single system or an entire data center.

The DR plan will include details such as recovery time objectives (RTOs) and recovery point objectives (RPOs). These define, respectively, how long you can function without a service and how current the data must be when you restore it. For example, RPOs may tell you that restoring copies of training materials from 48 hours ago isn’t a problem. But if your business runs on current stock market trading data, the RPO will show that you need data to be current within a few minutes.

Business Continuity Plan

The BC plan describes how you’ll maintain operations during and after a significant disruption or an incident. The BC plan should include a triage process for restoring the most essential operations first, such as filling customer orders, making payroll, supporting business partners, etc.

Your BC plan will explain how you can maintain operations in situations such as:

  • Encryption of your data by hackers
  • Loss of power to your facility
  • Failure of a supplier to deliver key materials
  • Natural disasters

The BC plan rests on the foundations of an overall information technology risk assessment and a business impact analysis (BIA). The BIA specifically identifies potential operational implications of various scenarios. What happens to your business if, for example, you lose access to a certain database or cloud-based software? How long could you withstand such an outage without major damage to your business? In a BIA, you’ll seek to put an actual financial cost on various interruptions so that you can make informed investments in prevention and mitigation strategies described in your BC plan.

Essentials for Every Plan

For all three of the plans described in this post, be sure to include these key elements:

  • A designated point of contact (POC) and a leader charged with heading up the effort in a specific area. Many compliance frameworks and private contracts require you to name your POC.
  • A schedule for updating the plan. Many companies are sitting on plans that have never been revised to reflect a remote workforce, reliance on cloud-based services, etc. Commit to an annual review of the plan and update it to reflect the realities of your operations.
  • A schedule for testing the plan. At the simplest level, you should do at least annual tabletop exercises. But you may determine that your situation requires more extensive testing.

For help assessing your specific business risks and making a plan to mitigate them, contact Pratum today.

Laptop with Completed Checklist and text Creating an Incident Response Plan

Recent high-profile ransomware attacks have motivated many organizations to dust off their incident response plans—or create one for the first time. If you’ve ever endured a breach, you know the value of a well-designed incident response plan. By guiding decisions in the critical first hours of an incident, the incident response plan can keep a minor situation from turning into an operational shutdown, as well as help your team track down the breach’s root cause, file cyber insurance claims, manage messages to customers and more.

A solid plan helps ensure that your crisis won’t ripple out to all of your clients and partners. A well-planned response prevents data loss, financial loss, impaired reputation and long-term damage to your business. Use the following guidelines to make sure you create an incident response plan that includes all the essentials.

Check Your Industry’s Requirements

Start by determining what others require of you. In many industry sectors, incident response (IR) plans are mandated by state law, federal guidelines (such as HIPAA) or your biggest customers’ vendor contracts. For example, more than a dozen states require any company in the insurance industry to maintain a written IR plan, among other best practices. And your cyber insurance underwriter will almost certainly offer you a better rate if you have policies such as an IR plan in place.

Guides for Creating Your Plan

One go-to standard for IR plans is NIST publication 800-61, known as the “Computer Incident Handling Guide.” This 79-page document provides details on tasks such as structuring an IR team, handling incidents as they occur and coordinating across departments and organizations. NIST’s approach boils down to this four-part Incident Response Life Cycle:

Incident Response Lifecycle

You should also review the SANS Institute’s more concise guide, known as the Incident Handlers Handbook. SANS recommends that every plan provide a specific process for these six areas:

  • Preparation
  • Identification
  • Containment
  • Eradication
  • Recovery
  • Lessons Learned

Where to Start Your Plan

Begin by asking these critical questions about your business:

  • Who are the critical staff?
  • What resources are available?
  • Who are the primary and secondary contacts?
  • What is the backup process?
  • How quickly would you recover from an incident?
  • How could an incident impact future business?

Before implementing an IR plan, let your staff know so they can understand why you’re writing the plan and what their role will be during an incident. Include pertinent staff members in creation of the plan so that they’re invested in executing the plan when an incident comes up.

What to Put In Your Plan

These are the key elements to include in your IR plan:

  • Your definition of an “incident” – This determines what triggers your IR plan. Typical situations that constitute incidents are loss or accidental disclosure of sensitive info, an intrusion or attack on the network or the discovery of a vulnerability that could affect operations. Vague definitions of incidents can trigger unnecessary IR responses even for low-level situations.
  • IR team structure – The team’s size depends on your organization’s size and complexity. The team plan should include:

    – An incident coordinator tasked with managing meetings, keeping notes and documenting actions.

    – People with strong tech skills, IR experience and an understanding of the business.

    – Multiple people with strong communications skills they can use to share information clearly and efficiently in the right directions.

    – Representation from key related areas such as legal, HR, and the physical facilities team.

    – An executive sponsor who can champion the team’s concerns up the ladder and provide visibility to the overall business.

    – A system for rotating IR team members on a planned basis to avoid burnout and promote fresh perspectives.

  • Roles/responsibilities – Clearly outline exactly who does what and establish a clear team leader. Some states’ regulations for certain industries require companies to officially report the name of the person of contact (POC) for information security. Be sure to consider duties your IR team may have in non-emergencies, such as training employees, monitoring threat alerts and participating in relevant industry groups.
  • Incident-reporting procedure – The team’s ability to respond effectively relies on finding out about the incident in a clear, timely manner. Describe whether notifications should take place through a help desk ticket, e-mail, phone call, etc. The plan should also specify procedures for preserving potential evidence. Your company’s ongoing security training should cover the incident-reporting procedure.
  • Communications plan for outside entities – You will probably need to notify people beyond your company war room about incidents. A chart like the one below from NIST shows the variety of parties with which you may need to interact. In your plan, establish clear rules of communication. Sharing the wrong information at the wrong time with the wrong entity could have implications for your cyber insurance, breach notification liabilities, class action suits, breach of contract claims and more.
    Incident Response Team Web
  • Post-event reporting – After the situation is resolved, the team should issue a report summarizing what happened and what remediations are required. Your plan should provide specifics on who will compile that report and the leaders who get a copy. Go over questions like, what went wrong? What went right? You should also establish a timeline of events to help answer these questions and see the bigger picture.

It’s easy for IR plans to get very long and complex, especially as you continue to revise it over the years. But you should focus on streamlining your plan to the essentials that people can realistically follow in the excitement and confusion of a real incident.

Building Your External Team

Just as critical as your organization’s internal team is the lineup of external service providers you’ll call on in an emergency. It’s essential to identify and build relationships with your providers in advance for two reasons. First, service providers that get to know your organization in normal times will be prepared to spring into action with an informed point of view at a moment’s notice. Second, securing the providers ahead of time will help you use your preferred vendors rather than being stuck with an unknown company from your cyber insurance carrier’s preferred provider list. Once you’ve picked a vendor, ask your cyber insurance company to add them to the preferred list to ensure that you get to work with your selected partners.

Your external vendor team should include:

  • An attorney with cyber expertise
  • A digital forensics team
  • A breach coach
  • Cyber insurance contact
  • Public relations firm, if your industry is in the public eye

Test Your Plan

Your IR plan isn’t a set-it-and-forget-it proposition. You won’t know if it works unless you test it. And you won’t know if it continues to work unless you incorporate a specific, regular schedule for review. At minimum, review it once a year. If your business is highly dynamic, it may require more frequent review. Common changes that prompt plan updates include:

  • Changing personnel on the IR team
  • Implementing new technology platforms
  • Winning contracts with new clients
  • Entering new geographic or industry markets with different requirements
  • Increasing budgets that expand your resources

Review the Aftermath

After you experience an actual incident and contain the problem, the IR plan should include steps for reviewing the incident. Ask what went right and what went wrong. Establish a timeline of events to help answer these questions and show you the bigger picture.

After the review, adjust your plan as needed. If a step in the process didn’t go as planned, figure out why and make changes.

If you need help creating an IR plan tailored for your specific situation, contact Pratum today.

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.