Every career has a set of skills that one needs to do their job, and a set of tools to carry out the various tasks required to display their skills.
The simplest example of this is an auto mechanic. He needs the skills to know how to fix your car when it breaks down, and the tools like a wrench to actually do the work.
In IT Security things are a little different, some tools don’t fix things, they break them.
In the third phase of the security lifecycle, security practitioners take out the tool chest (aka CD-ROM) to test all that hard work you have put into that project.
The objective really is to assess the architecture and design to ensure the processes and controls are working as you expect them too.
In other words, we are providing some accreditation and certification to the design that it hopefully is in-line with the values and policies of the organization.
We use network scanners to identify targets, application assessment tools to find holes, and exploit code to pop open doors and secret access points into your applications.
When a security analyst is doing a security threat and risk assessment, they are really playing the role of would-be attacker, and I will tell you, it is fun.
If you take three security analysts and tell them each to asses the same design, you will get three different reports with three different risk ratings.
This is because assigning risk can be subjective to the opinion of the assessors experience and understanding of technology.
Take for example an assessment of a web portal. It uses a mixed environment where some information is sent over an SSL encrypted tunnel, but other non-sensitive information (pictures, ads, etc) are allowed to continue over HTTP. To get access to the sensitive information a client must sign-in.
One analyst walks through their assessment and finds that the authentication is working and requires a strong password and notes that the non-sensitive data transferring over non-encrypted channels is of low-risk to the organization.
Their college however has a completely different take. During their assessment it was determined that the sensitive files are contained in the same directories as the pictures, and that by changing the link to the picture to that of a document, you could view it without authentication. Risk was determined to be high.
What happened? Why didn’t the first analyst find this exposure?
The answer is, they each followed a different process to do the technical assessment, and this is why I have chosen the all mighty checklist as my tool of choice for this article.
What about all those Cool Tools?
I know it isn’t the coolest example of an information security tool out there, just look at the toys I play with over at http://sectools.org/ , but it is one of the most important.
A checklist can offer you a continuous, repeatable process to ensure that issues like missing unsecured directories structures are not missed.
They are a tool that can be used by anyone and is mostly understood by all. Start at task #1 or the first line and work down until complete. If the finding is yes, give the box a tick, otherwise X marks the spot.
Checklists don’t have to be complex, or pretty, or even personable if they are just for you.
Microsoft Excel is a really good tool to use to create checklists, Microsoft Visio, Adobe Acrobat Pro, or others are more robust if you need something fancy or interactive.
What makes a Good Checklist?
Creating a good checklist requires trial and error, after several revisions you will have something rock solid. For a good example of this, take a look at the Department of Defense.
The have a product called a STIG. Security Technical Implementation Guides. http://iase.disa.mil/stigs/index.html
These are checklists that people responsible with installing an operating system on DoD equipment must perform in order to meet the DoD standards.
Being a military process, you can imagine just how detailed these checklists are; however, take note that these have each gone through several updates.
To create a worthwhile checklist that will be used as a business assessment tool, it needs to align with the business requirements.
Business requirements are outlined in the various policies an organization may have.
An organization policy might say “All data in transit must be encrypted”. When you create a checklist for an assessment, having a task like “Validate data transfer occurs over encrypted channel” would ensure you are aligning the assessment.
Break it Down
If the tool is to be used by others, make sure it can be used by a 5th grader. Have a small description at the top of the document dictating how to use it, and make sure the creator of the document has some contact details listed.
Break the procedures into major sections, such as People, Process and Technology, or, if it is all about technology, Operating System, Networking and Application.
This gives the operator break points in the process to stop, grab a drink, and come back knowing where they left off.
Maintaining a checklist is an important step, especially when there is a new release of a product, a significant policy change, or a new validation that needs to occur.
I use checklists just to make sure I have everything I need to do an assessment before I actually do one. Here it is:
||Reviewed Architecture Docs
||Cataloged OS versions
||Documented know vulnerabilities
||Updated Toolset with latest rev
||Validated Tool integrity
||Received Sr Management OK
||RFC date scheduled
Pretty simple and boring, however, if I missed item 3 – Received Sr. Management approval by failing to use the checklist, and during the process of carrying out the assessment I crash the corporate payroll service, I have a problem.
Checklists with Flowcharts
For a more advanced checklist, you can build one inside a flowchart using something like Microsoft Visio.
A flowchart checklist helps with variables in the process; if this then that, type of situations.
For example, if the task on a checklist says “Does the application require strong passwords?” then there are three possible outcomes. The flowchart guides the operator through each branch of the process depending on the finding.
Flowchat checklists take up more real-estate on the screen and in paper form, but if the process is to be used by someone foreign to your methods, it is the best solution.
For taking the time to read through this article on the ever exciting checklist, I offer you this “cool tool” reward. (Windows systems)
Open up you windows command prompt by selecting Start->Run and typing in cmd.exe
At the command prompt type (case sensitive)
net statistics server |find "violation"
If you don’t see zero then there have been attempts by unauthorized means to access your computer.
netstat –nb |find “ESTABLISHED”
You now know who is connected to your computer.
cacls "any file or folder directory”
You now know who has permissions on the file or folder your queried.
Author: Stewart Allen is a certified Information Security Consultant with over 12 years of experience specializing in Health Care and Financial Service industries. Acting as an Information Security Advisor, Mr Allen is responsible for finding opportunities for his clients to achieve their business goals, while helping to ensure information assets are secure. If you would like to learn more about the author he can be found on LinkedIn at http://www.linkedin.com/in/stewztheone