Proven methodologies in creating a strategy

In this section, we're going to cover some proven methodologies that ensure a high level of success for creating an information security strategy. We'll discuss creating information security policies, procedures, and playbooks, as well as establishing and maintaining a security awareness program, managing third-party risk as a responsibility for any information security professional, and reporting and continual improvement as a focus for highlighting the progress that's been made, which is something an information security professional must consider in an era of growing cyberattacks and increased reliance on digitalization. With these topics in mind, you are setting yourself up for success, with the opportunity to improve and cater the strategy to any long-term goals or changes to the landscape. Let's begin by talking about creating an ISMS.

Creating InfoSec policies, procedures, and playbooks 

Information security policies, standards, baselines, guidelines, procedures, and playbooks are the backbone of any information security strategy. We have already established that point in this chapter. With that said, how do you make those? How can an individual person manage to create all these documents, full of terms, guidance, and policies for an organization such as The Ketchup Company?

Creating an ISMS is an important undertaking for you and your organization to have the appropriate level of visibility into its information security risk. I am going to cover the process of creating an ISMS further in Chapter 2, Protecting the Security of Assets.

Until then, keep in mind that the key to finishing a marathon, a hill climb, or any other metaphor for the daily slog of your job is the same: you begin by taking a single step. Taking each hour at a time, and plugging away at creating a structure suitable to your organization, is going to ensure better visibility and fewer unknowns. When you encounter information security-related topics in your day-to-day conversations and experiences at work, write them down and keep notes. Notice what people say, do, and what happens most often, and use that information to help in your ISMS project.

Establishing and maintaining a security awareness, education, and training program

The information security policies need to be understood by all the members of the organization. The requirements need to be established immediately to any new member, and regular reminders need to be provided afterward. Furthermore, keep in mind that you will need to train key staff members on the entire information security program, and other staff members on key points that cater to their jobs. You want to make sure the organization isn't relying on you (and only you) in the event of any outage. You do want to be able to take a holiday, don't you? Beyond that, you want the business to be able to react even after you're long gone, and you want staff members to be aware of their responsibilities when it comes to various information security topics and scenarios.

As a result of that, you are going to want to create training materials to ensure the members of your organization are educated and trained on their requirements from an InfoSec perspective. With new members, depending on the nature of your organization and its size, you might set aside a few hours to introduce yourself and talk about the information security policies of the organization, or you might need to formalize the process a bit more into documents or training videos in order to scale. Generally, new members of an organization will sign an agreement to uphold the policies and practices that have been covered, and that agreement is kept on record and updated annually.

Many people in this industry say that employees are the biggest vulnerability to your organization, and imply that it's the fault of the employee if they are tricked by a phishing scam, for example. To that, I say, "How can we blame the victim?" Let's look at a few questions we might want to ask:

• Was there adequate training in place?
• Were there phishing simulations conducted to identify the at-risk employees?
• In their day-to-day work, was there a secure method of performing their tasks available to them?

It is likely that the information security team's responsibility is to ensure the members of the organization are educated on the threats they face. There are so many effective ways to turn a person who would have originally been a liability into a champion for your security strategy, just by showing them how interesting the field is, and by providing incentivization. This is the value of creating engaging and interesting training materials, and this idea should never be neglected in your overall information security strategy.

Managing third-party risk 

To be perfectly honest, the cloud is the way things are headed. Newsflash, right? Even the slowest, most risk-averse businesses are heading to the cloud. Banks are moving to the cloud! Governments are moving to the cloud! You name it. From Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure for hosting, to Office 365 and G Suite for documents, to millions of different SaaS products for project management, source code repositories, accounting software, HR management, data loss prevention, SIEM, and the list goes on and on, the solutions that are being offered to manage information in the modern era are increasingly shifting toward the Shared Responsibility model, and part of the risk your organization faces becomes a third-party responsibility to mitigate. How does that third-party cloud accounting software secure their estate? Do they make that information available? Just because you're not hosting the software on your own servers doesn't mean you are relinquished from all responsibilities when it comes to security, compliance, due diligence, and risk reduction. Your organization's data is being processed by assets under the third-party's control, but it's still important to consider as part of your responsibility.

Utilizing various Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) solutions presents new requirements: crossing international borders with PII is now potentially breaking the law. A third party storing your organization's data in plaintext could be catastrophic in the event of an insider threat viewing that information. Running your platform on a third-party server that, unbeknownst to you, is unpatched and vulnerable to exploits that are readily available on the web? There's another risk to your organization's success. How can you possibly mitigate this? Isn't it the responsibility of the cloud service provider (CSP) to update their systems or encrypt your data? Not unless they have agreed to such, most likely. How can you ensure an organization says what it does and does what it says?

First of all, you'll be happiest when you have legally binding Service-Level Agreements (SLAs). SLAs are a promise from a third party that they will keep their service to a certain standard of availability, confidentiality, and integrity, among other things. As an example, often, a cloud IaaS SLA might deem that in the event of an outage that causes availability to drop below 99.9% (or 99.99%, or 99.999%) for the month or year, the third-party will reduce the costs to their client. This is sometimes referred to as "three nines," "four nines," and so on. It's a way for your organization to mitigate availability risk by offsetting the monetary loss experienced from that loss of availability. In a way, your SLA is a legally binding control that you are able to report on and ensure is effective. SLAs are negotiable in the sales process and can sometimes go back and forth between the client and supplier multiple times, with redlining and pushing back from either side before an agreement is made. If you work at a CSP, you might find yourself as the information security professional who's responsible for negotiating the SLAs on the other side as well.

In addition to SLAs, you could use what is known as a Vendor Security Assessment Questionnaire (VSAQ), which is able to be completed by any current vendors or prospective vendors. What these VSAQs do is ask a standard set of questions for due diligence purposes and record-keeping. The response to these questionnaires should be considered during the procurement phase, with risk as the backbone of that analysis. Generally, a VSAQ will go over the security program of the vendor, any controls they have put into place for protecting their estate, the training and awareness that the employees undertake, and the types of audits (along with the audit results) that the vendor regularly undergoes. VSAQs are a way to get an account on record from the person in charge of information security at the company you're paying to process or store your organization's confidential data, business processes, and PII or PHI.

It is your obligation to show that due diligence and due care has been put into each and every decision for outsourcing data processing and storage to a third party. In the event of a breach at the third party's estate, you want to be able to show that you made an informed decision based on the testimony of the third party's questionnaire answers. If they don't treat a specific threat the way you would like, make a note of it, and potentially even discuss the matter with their information security team. You might find out that further improvements are actually on the roadmap.

Don't worry about being a pain when discussing SLAs or VSAQs. Any vendor worth your time has had to answer similar questions and negotiate similar terms with other organizations, and might even have those answers prepared. If you're working at a CSP and are responsible for answering these VSAQs yourself, then you would be very right in cataloguing your responses to those questionnaires, along with creating a VSAQ FAQ. It will save you countless painful hours of repetitive work. In previous roles at SaaS vendors, I've had a privacy and security whitepaper prepared, which answered every question asked in the VSAQs, with drawings and technical details provided, which I would then initially pass to each prospective customer for them to look through and fill their own questionnaires out. It was very helpful in the months leading up to GDPR's effective "start date," where a thousand customers were scrambling to prove due-diligence and due care by crafting their own version of a VSAQ and sending it out to all their suppliers.

Google's VSAQ web app (https://opensource.google/projects/vsaq) allows a vendor to either complete their answers via the app or load their answers from a file, and then submit their responses to standard VSAQ questions. Unfortunately, I haven't seen nearly enough vendors or customers using this format. It would save so much time to just standardize and create the "gold standard" VSAQ and let us all get on with making our organizations more secure. Another type of questionnaire is the Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CAIQ), available at https://cloudsecurityalliance.org/artifacts/consensus-assessments-initiative-questionnaire-v3-1/.

Keeping this information in your ISMS is important in the event of a third-party breach. As we mentioned previously, you want to be able to show an appropriate level of due care. If you can show that the risk has been measured and deemed acceptable, it could help show that you weren't being negligent. It may seem redundant, but regulators and stakeholders will want to know the details that led to a decision, because they may have to answer to board members, stakeholders, customers, regulators, law enforcement, or governmental entities on the matter.

Continual improvement and reporting

Another important thing to remember is the ideology of continual improvement. New exploits become available, new techniques surface, and systems change constantly. As new vulnerabilities are discovered, and as new threats arise, all of the implemented structures and controls for reducing information security risk at your organization need to get better. It's important to keep up to date with what is happening from a threat and vulnerability point of view, as well as ensuring your asset and risk registers are up to date.

If any of the organization's controls fail or can be circumvented, where does that leave you? If the answer is "wide open," then you don't have a sufficient amount of defense-in-depth. It's an important concept to grasp: double-locking. Adequate defense-in-depth might not reduce risk, but instead allows for a control to fail and you to still have a reduced residual risk.

In addition to defense-in-depth, looking at the world through an engineer's lens is highly beneficial to an information security professional. You can improve processes and systems to make things more lightweight, faster, automated, effective, scalable, accessible, and less expensive with fewer errors. Reducing the costs of one control allows you to build more defense-in-depth and reduces complexity, which is the enemy of security.

In order to chart your progress, you could keep legacy versions of your risk register, potentially by financial quarters, or halves, or years. It will give you a great dataset for the impact you've made at your organization, and will help you justify that pay rise they've been hanging over your head for the past year. Make graphics, put them into PowerPoint presentations, and regularly update your stakeholders at your organization with the progress, wins, and blockers. Depending on your organization, and if you're sitting in the top information security role, you could include the CIO, CTO, CFO, and potentially even CEO in these conversations. Also, the legal and HR departments will have an interest in the topic of insider threats, legal obligations, and other compliance requirements. Don't waste their time, and make sure to keep things non-technical and high-level, catered for C-levels who only care about the bottom line: "How much does this cost, and how much does this save?" You can show your program's return on investment by utilizing risk reporting.

Sometimes, you'll find some really interested stakeholders in these meetings, who are impressed with the findings. Other times, you'll find some people who don't really care, and are just there because they have to be. Make sure to give all your audience members a reason to care. The CFO is going to care about different things than the CTO, but they both have their own reasons for wanting to keep the lights on and the money coming in.