Security From Scratch: Getting the Lay of the Land

by Dennis Kuntz

“You rush a miracle man, you get rotten miracles.” – Miracle Max, from The Princess Bride

When building Security from Scratch, the challenge is in undertanding the situation from the start. Once the team is identified/assembled, the focus shifts rapidly to getting a handle on the security posture of the organization. This is not an “assessment” in a formal sense, but is more involved than simply checking for a firewall and antivirus.

Each situation is unique, but here are the areas I consider in my tactical review so I can understand what challenges lie ahead and form my plan of action:

• Information Security Policy
• Network/Perimeter Security Posture
• SDLC Security Policies/Procedures/Practices
• Applicable Compliance Requirements
• Security Awareness

I’ll share my approach and thinking below – but want to hear from you, too. Are there other areas you would include, avoid or otherwise consider? Leave a comment or send an email and we’ll expand together.

Information Security Policy

This is an area open to debate, but I like to check for and review the existing security policies. It provides insight into what, if anything, has been done. It generally provides clues, too, to why decisions were made.

I’ve found two major approaches to Information Security Policies:

(a)  a monolithic approach where the policy encompasses all areas with details

(b)  a piecemeal approach where you have a very general document that references more detailed documents.

If I get to choose, I prefer the piecemeal approach. It allows employees to get an overview of the policy and all of the areas covered, without overwhelming them with too much all at once with one huge document they’ll never read.

With the “piecemeal” approach, the details can be spelled out in the referenced documents that are easier to draft, update, and distribute.

Understanding the current approach and structure helps form a picture of the current environment. Here are some questions to ask when considering the existing Information Security Policy:

• Does a policy exist?
• Who wrote it, is it strictly boilerplate, and/or has it been reviewed by stakeholders and approved by management?
• Are the policies being followed?
• How are changes made/approved?
• Who currently maintains the policy?

Network/Perimeter Security Posture

Now, while I suggested just checking for firewalls and antivirus aren’t enough, it doesn’t mean they should be skipped. It’s too easy to limit one’s assessment of security posture to just those kinds of elements. With that said though, this is definitely something that should be included.

In addition to getting a good idea of the network architecture (diagrams, etc.), here are some questions to ask regarding the network and perimeter security posture:

• Is remote access allowed? If so, how – VPN, SSH, nothing?
• Are firewalls , WAF’s (Web Application Firewalls), and/or IDS/IPS’s employed? Where? Who manages/maintains them and their rule sets?
• Does your company have/maintain a DMZ?
• Is wireless access allowed from your premises (including both network access as well as “open” wifi)?
• Does your company have any resources/assets in “the cloud”?
• If in “the cloud”, what control does your company have over the security of resources, vs. those that are simply “built in” to the services offered?

This is obviously not a comprehensive list (if you think I missed something key, drop a comment).

The main focus is to get a tactical understanding of the network and potential points of exposure. While tactical, this allows the identification of strengths and weaknesses in the current layout to form the path to advance the posture.

Once the tactical review is done, it is important to run internal and external assessments to test the baseline performance of the existing controls. Ideally, this should include both comprehensive vulnerability assessments as well as comprehensive penetration testing. This can be easily handled in-house if budget is a challenge.

SDLC Security Policies/Procedures/Practices

It should be obvious that companies that conduct business on the “Internet” , develop software, or has any measure of internal development, that SDLC (System Development Lifecycle) practices are important as they relate to security.

However, this also matters to companies with only a web site that was created externally and is hosted/maintained by a third party ASP (Application Service Provider), with no internal development. When getting the lay of the land, take a look at the accepted development practices to make sure they take appropriate security measures into account.

Here are some questions to can ask :

• Who “owns” the SDLC?
• Is security specifically addressed in any SDLC documentation, especially regarding applicable best practices (i.e. OWASP Top 10 for web application development, buffer overflows for vulnerable languages, etc.)?
• Is there any formal secure development training available for developers?
• If third parties/outsourcing is used for development, are security practices published and/or open for review?
• What is the current state of security awareness among the developers, architects, etc. (this can be assessed by one-on-one interviews with developers, architects and managers)?

As with the Network/Perimeter Security Posture section, being able run assessments and have penetration testing done will go a long way toward establishing the effectiveness of current controls.

Applicable Compliance Requirements

If the company is subject to any compliance requirements, it is vital to establish the current state of compliance. I will be covering this topic in more detail in a later post, but here are some questions you should ask:

• Is the company subject to government compliance (SOX, HIPAA, etc.)?
• Is the company subject to non-governmental compliance, such as PCI-DSS?
• Does the company need to remediate any recognized compliance violations and/or is there a deadline for any existing compliance efforts?
• Regarding existing compliance efforts, where/how far in the process is your company?
• Who or what department oversees any given compliance effort?

As noted in the first installment of this series, establishing relationships with other departments –especially regarding compliance – can go a long way toward achieving your company’s compliance goals.

Security Awareness

While “Security Awareness” can mean different – and specific – things to different people, I’m referring to it here in more general terms. In essence, you need to take a look at your company’s current behavioral and cultural stance and openness toward information security. Here are some questions you should ask:

• How much support will you have from stakeholders? From management? From everyone else?
• Related to the previous question, how much latitude will you have in making decisions – will you get to run the show, or will you end up having to be an order-taker?
• Is your position the culmination of a concerted effort to “become more secure”, or is it the result of a begrudging attitude to achieve a bare minimum? The answer to this one may take some effort to answer honestly….

Turning Your Eyes Toward Defining – and Achieving – Success

Once you have all of this in place – your team and a good idea of where you are – you can begin to understand what is needed to define “success” and the metrics needed to quantify that success.