Security Standards

Having a security standard in your risk assessment process is a lot like dating. You probably started dating without creating a premeditated standard of what you were looking for. But as time went on, you started to notice some things about the person you were dating. Eventually creating a standard of what you hoped and expected.

Security standards are much the same. They create a baseline of expectations that drive a minimum set of controls and are used to drive security conversations.

Most security teams will not have security standards specific to the technology they are assessing before they do the risk assessment. But as they perform the assessment, talented and experienced team members start to see, feel, and hear things that are noted to be included in a security standard.

The reason I’ve provided this analogy is that this step of having a security standard might vary from company to company, or group to group, or even within time.  For example, the first time you perform a cybersecurity risk assessment on a CRM solution you probably won’t have a security standard. The first time you perform a risk assessment on ERP you won’t have security standards. But as time goes by you will start building these standards.

Three components influence security standards.

1. Industry best practice – Published guidance on recommended controls.
2. Company culture – The level of security standards already set within the company. These include privileged access management (using separate service accounts), single-sign-on solutions (like Okta), and even network zones for external access, and the use of production data on development systems. MFA on all external authenticated. These standards that have been set as the ‘standard’ can be inherited to these new system standards.
3. Specific risk mitigation standards.

 

Let’s walk through each of these components to building a security standard. Based on this systematic approach you’ll be able to quickly create brief and straightforward security standards for the technology you’re assessing. These standards will be used as the core of your agreement with the business and serve as a critical component to show the risk visibility as a result.

 

1. Industry Best Practice

As a cybersecurity expert, your time is valuable. Leveraging a documented, already created, security standard saves you a lot of time. It also can save you a lot of time on the back end by reducing the time spent answering people’s questions. Questions like, ‘Where did this setting come from’, ‘why do we need that turned on’? By reflecting your response to an industry-standard you’ll save you time defending the standard. All the while, giving you the freedom to adjust the standard to your specific business.

Some great security standards for operating systems have existed for years. CIS provides an extensive list of security standards already available, and often in different levels of risk.

As we go up the OSI stack, these published standards become less and less available. In today’s world of SaaS applications, you’ll find it harder to find published standards.

 

2. Company Culture Standards

There are security standards that have already been set within your company. This is the time to review them and inherit them for this new system.

These standards often include:

• If production data can be used in the development
• If the vendor-hosted system has an SSEA16 or SOC2 attestation
• If the Multi-Factor Authentication (MFA) is required on external systems
• The certificate authority requirements, or SSL protocol standards
• Single-Sign-On solution integration requirements.

 

Something I like to do, for organizations that perform enough assessments to benefit, is to create blanket security standards for service platforms. For example, take all your requirements that you’ll always have for SaaS applications and create a ‘SaaS application security standard’.

Create another one for ‘Vendor Hosted Application Standards’.

These standards serve as a bar, the minimum expectations for systems introduced to your company.

They can also serve as speed bumps. They buy you more time. They are documents you can give to the business unit asking you to perform a security assessment, and ask them to review the published standard for this technology.

I do want to be careful here. I’m not for pushing back. I’m all about building relationships. But with that said, you can use speed bumps If you need to.

3. Specific Standards

Even though you have a great set of industry standards that may or may not cover this technology you’re accessing, and you have company culture standards, there will most likely still be security configuration settings specific to the solution you’re reviewing.

Let’s take Salesforce for example. Salesforce is a great solution. Salesforce cares deeply about security. I know because I’ve been to the Salesforce convention and they invested in a security consortium for us to discuss security issues. I’ve personally performed several risk assessments on Salesforce. With that said, if you set up a default implementation of Salesforce, I say you have significant risk. And Salesforce knows that too.

There are parts of the system and data controls the vendor provides. And there are parts the user of the system is responsible for. These are called the ‘User Control Considerations’, or UCC’s for short. They also go by other names, but essentially this is what you’re looking for.

Find the UCC’s for the system, and review them. Decide on what settings are important to you and what configurations you want to enforce through the documentation of a standard.

Here’s a great learning module from Salesforce that helps educate on the security control settings: https://trailhead.salesforce.com/en/content/learn/modules/security_basics/security_basics_features

 

Scope

Save yourself a lot of time by considering the scope of the system being implemented. The majority of cybersecurity risk assessments I’m seeing come across are for SaaS applications. The business wants a new application that is going to help them increase productivity, save time, and/or make more money.

Don’t concern yourself with creating a standard from the bottom up. Only consider the scope of what needs to be secured. That means you don’t need to include the platform (O/S) standards.

Less is more. Standards do not have to be lengthy. Short and to the point. Just like policy.

(side note: I’ve always advocated for a super short infosec policy that just says, “Don’t be stupid” No client has allowed me to that yet.)

 

Summary

These steps should help you develop a security standard for the technology or platform you’re reviewing. The standard can be used in the cybersecurity risk assessment process by supporting the business initiative as long as the system is implemented and configurated according to our security standard.

Having a security standard also helps the advisory process with the business by explaining where the concerns are;

• Are they external concerns about the vendor responsibility?
• Are the internal concerns about how it’s implemented?

Creating a standard for platform levels can save you time by covering the majority of security expectations across several systems.

Later I’ll provide a template for you to speed up your risk assessments so that you can focus on the technology security aspects, instead of the political paperwork.

 

Previous Article: