Risk Management Frameworks

Risk Management is receiving much more emphasis in security today than ever before. Risk Management certainly is nothing new, and has existed in many different forms over the years. I remember when I was in the Navy around 1997 I was first introduced to Risk Management in the form of ORM - Operational Risk Management. Having recognized this trend, I decided to study and test for the ISACA CRISC certification this December. You can find the basics of Risk Management through my blog, but this is a much deeper subject than what I have posted. To completely understand Risk Management an intense study is required. Just to put that into perspective a little bit, the CRISC manual is ~400 pages.

ERM is probably the most popular form of Risk Management. Various models exist for ERM such as CAS, COSO, and OSI's ISO 31000 and 31010. Tools like OCTAVE, developed by Carnegie Mellon and released in 2001, are also useful in identifying risks as well as the FISMA Risk Management Framework.

ERM is also being imposed upon companies by U.S. law in several cases. Sarbanes Oxley is just one such case and requires risk management in support of identifying fraud and fraudulent transactions. Even setting legal requirements aside however businesses are seeing increased value in earlier identification of risks and implementing risk management frameworks.

Risk can exist on many levels. There is overall risk to an organization as a whole, which may or may not be shared in common with each division, department, or work center. Because of this it is important that all risks are identified, cataloged, and reviewed regularly.

Risks are constantly changing which makes them dynamic and hard to track. Because of this risk must be evaluated regularly. Annual or semi-annual reviews should be conducted. Risks should also be evaluated immediately upon any significant change. This could be changes in market conditions, changes to an IT system or infrastructure, moving offices, and a variety of other possibilities.

Perhaps the most beautiful thing about Risk Management is its versatility. The topic itself is very broad and applies to many things while the principals used are always the same. One visit to RIMS and you will easily see that risks vary broadly from credit ratings, to terrorist threats, to newly identified software threats, and even risks associated to various processes. I think it is safe to say that Risk Management is here to stay, is still in its infancy even though it's been around a while, and represents a promising career for anyone interested.

Password Security

Tonight I was just reading this article. First, let me state that while I disagree with this article, I do see their point. I just happen to think that leaving it up to individuals to discern between which sites to use/not use "throw away" passwords on is risky. I'm also of the belief that relaxing this posture will create a lazy culture. Reading this made me wonder what would be worse, taking an approach like this, utilizing 1-5 complex passwords across multiple sites, or using some sort of password wallet software? Maybe there are other scenarios, but these are the ones that quickly came to mind during this 8 second popcorn thought. We really need to just go ahead an make the transition away from passwords.

Vulnerability Scanning: Identifying False Positives

It's been a while, but I appreciate the patience of my audience during these trying times.

I want to talk about vulnerability scanning today and false positives because I see so many misunderstandings and people addressing this incorrectly. I regularly hear popular opinions that vulnerability scanners produce above a 90% false positive rate. First off let's address a common misunderstanding between security personnel and administrators. Often times the security administrator wants the admin to relax certain security settings so that the scan will get every possible result. Why? This seems kind of backwards to the admin.  Why would you want to relax the security settings?  Because we are interested in finding every possible patch or configuration that needs to be fixed. Let's be honest, if I'm the Blackhat and I'm effectively attacking your network, I'm going to be looking for every possible attack vector. Some of these the administrators may "think" they have mitigated, but perhaps their mitigation is ineffective resulting in a control gap. What I said in the previous sentence is really the keyword too, mitigated.  The flaw is still there, just better masked.  Allowing the vulnerability scanner to detect every vulnerability possible is a greater mitigation, or at least can lead to greater mitigation. Also when we scan, we want accuracy. An open network reduces the opportunity to generate false positives.

False Positives! This is a biggie! In vulnerability scanning, a false positive is when the vulnerability scanner returns a finding when in fact that finding is not there, or in other words a vulnerability has been detected when in fact patches, configurations, or mitigations that address the vulnerability are already in place. Sounds fairly straight forward right? Well, it's not. This is an area that is regularly misdiagnosed because only the truest security professionals actually know how to properly diagnose it. For example, let's say we generate a report for a windows system and hand it off to an engineer or system administrator. They are likely to glance at the report, see an MS article, lookup up the associated KB article, and see if it is installed in Programs (Add/Remove Programs). Sounds logical, but there may be more to it. Much more in fact. Let's say that a patch deploys a new dynamic link library (dll) file. The newly installed .dll file may not be vulnerable, but if the old .dll file wasn't removed during installation, that system could still be vulnerable. Why? The answer can be found by asking what is a .dll file. In the most simplest of terms, a .dll file creates modularity by providing common functions through a single avenue. This means that if the .dll file is present, it can be called by malicious code. So, yes, maybe whatever app was using the .dll isn't vulnerable any longer since it points to the latest, but the vulnerable .dll is still present and thus vulnerable. If it is there it can be called, which makes it vulnerable.

This isn't the only mistake I've seen in identifying false positives.  Another common mistake comes from networks with short DHCP leases or removable hard drives (classified areas).  In practice I have seen very well trained engineers dismiss vulnerability scanning reports simply because either a lease expired and the IP can no longer be identified.  In the case of removable hard drives I've witnessed administrators ping for the IP listed in the report, and close the finding when the system is unreachable.  In the case of removable hard drives, I understand that there are certain circumstance to overcome, but typically from what I've seen removable hard drive environments are a 1:1.  That is to say that the hard disks are labeled to be for a specific system.

I've been conducting vulnerability scans for about nine years of my eleven years in information security.  During that time the one thing I hear regardless of the site is that vulnerability scanner findings are 90-99% false positives.  In practice, I'd be lying if I said I have never seen a false positive, but the fact of the matter is that if you know what you are looking for, the vulnerability scanner is typically correct.

Think about it for a second.  The programmers that are writing these scanner rules are not throwing darts in the air and hoping they hit something.  They are writing their code based off of requirements, most likely coming from CVE, BID, or vendor KB that identify what to specifically check.  Then they automate that check and release in an update or in the latest engine.  When you really take the time to break down a vulnerability scanner check, understand how the technology works, and compare the findings against CVE, BID, or vendor KB the finding is typically correct, and thus represent a vulnerability.

In conclusion, BEWARE --> BE KNOWLEDGEABLE --> BE THOROUGH!

Vulnerability Scanning: Creating Scan Groups

At most sites in my experience, vulnerability scanning begins by doing a discovery scan, creating groups, assigning policy, and then proceeding on with scanning. These scans eventually will become reports that will go out to some entity, but there are some up and down sides to this approach.

First, let's look at doing a discovery scan. How do you do it?

Vulnerability Scanning: Best Practices

This is the first of what will be a series of posts about vulnerability scanning.  This particular post will be fairly generalized, but the next two to three posts to follow will be more in depth.


Vulnerability scanning is something that every organization should do. It can drastically help improve an organizations security posture. There are many different ways that a vulnerability scanner can help your organization to build secure systems, validate maintenance and patching of existing systems, and in some cases ensure legal compliance.  In any case it is important to make sure that scans are being run with administrative privileges.

Outdated Software and Your Privacy and Safety

By now everyone has heard of Malaysian Air Flight 370, the plane that disappeared somewhere over the Indian Ocean. Early reports were speculative that the aircrafts systems may have been hacked, causing it to become unresponsive and even be remote controlled from somewhere else. There were even claims of proof of concept ideas that this has already been demonstrated using models and Android phones. Is it possible? Yes, it might be.

The Importance of Independent Auditing

There are some simple concepts that we encounter regularly within information security - conflict of interest, least privilege, and separation of duties to name a few. These simple concepts are what make independent auditing such an important concept. The concept of independent auditing is a requirement in order to get an honest, and true-to-life review. An accurate audit is important because it could identify weaknesses and/or flaws in processes. These weaknesses and/or flaws could lead to public embarrassment if not handled properly before becoming exploited, loss of trust, or even legal implications in some cases.

Security Awareness Programs

These days just about every organization has a security awareness program, and yet people are still the weakest link. Why? How could this be? People are generally good natured. They want to help. This simple characteristic is what makes social engineering such an excellent tactic even today. The tactics are simple. Ask someone a series of questions, start out simple, and progress into other more revealing questions. Another tactic of social engineering is to make regular contact. By doing this you develop a persona and become someone likable to the target. Each time you call not only are you developing a persona, but you are also slowly collecting useful information that you can use for research in between contact. All the while the person being targeted has no idea. Those that are really good at this tactic essentially hack the mind. They can lead a conversation directly into the direction that they want it to go.

Evolution of a Security Engineer

Everyone has a story.  For me it started in 2003.  I had been recalled to Active Duty from the Naval Reserve as a Unix Administrator.  I knew nothing of IT or Unix back then, but I did hold the qualities that employers look for - fast learner, on time, driven, etc. 

The short version of my story follows. My orders were up and I would have been going back to working four jobs - bagging groceries, naval reserve weekends, band gigs, and college.  The Air Force Technical Sergeant that I worked for knew I was worthy of much more.  He had a cigarette with another guy on one of my last days.  This man was looking for entry level IT Security people to become intrusion analysts.  I met with him and he asked me what I knew about TCP/IP.  I told him I could spell it, and he told me to go to Barnes and Noble, buy two books about TCP/IP so he knew I was sincere about the position, and I would be hired.  I did obviously.  I put myself on twelve hour nights purposely for the first year and a half so I could read, use the lab, and catch up to the required skillset and the rest is history.  It was pretty much a lucky break, and along the way I've been extremely lucky to have worked with some great mentors and people that have helped me grow quickly, coupled with jobs that make for an outstanding resume, and of course...a little hard work. I've had the luxury of growing up in security, and as such have worked the gamut over the past 11 years.  But enough about me.  What about everyone else? 
I would venture to say that most security administrators are prior server admins.  Most have probably come through the traditional IT ranks - helpdesk to client support, client support to server support, small environments to large enterprises.  Why?  Because our field is still young.  Most are converts from networking, server administration, or were administrators of security tools. 

Either way you came up, we all have new hurdles to overcome!

The Importance of Policy - Overcoming Personalities in a Flat Organization

On 2/9/14 I posted "The Importance of Policy" and promised at the end that I would follow up with some ideas on enforcing policy within a flat organization. To recap, the original question was basically this - If you are reviewing someone's project and find that they are not following policy, inform them of the offense, and they refuse to comply what do you do? Let's start with tackling this domestically. The first thing to look at is Maslow's Hierarchy of Needs; physiological needs, safety needs, love and belonging, esteem, and self-actualization. In it Abraham Maslow describes people as needing to be accepted and respected. How this occurs in a business environment is bureaucratic. In other words, the most important acceptance for the individual comes from his or her management chain. Maslow also describes a need for safety which encompasses work. In other words, nobody wants to lose their job and as such should be willing to comply if approached in the correct manner. Esteem and Self-Actualization are also key parts in Maslow's hierarchy which could be related. Encountering someone with low self-esteem may give the person making an argument the upper hand, if in fact the arguer has a higher self-esteem. Self-Actualization encompasses understanding the situation, making decisions, being moral and ethical, problem solving, and objectivity. This is an example of someone reaching their full potential. Maslow's biggest criticism is not being worldly. It is heavily weighted in domestic research. So what do we do in a global situation? The answer is simple. Look toward a global model, Max Neef's Fundamental Human Needs. The same ideas as listed above apply, although they are classified differently in this model and are not considered a hierarchy. The biggest difference for application here is how those needs are satisfied. Being able to answer this question for each need makes this model cross-cultural. Juan Antonio Perez Lopez' "Organizational theory: A cybernetical approach" may have some answers for motivations and interactions.

Phone Scamming: Alive and Well

I've heard reports recently of specific social groups being targeted for scamming.  I hadn't paid much attention to it really until recently.  I was targeted as was my Grandmother and Uncle.


I have a friend and colleague that recently took a trip to the islands.  Upon his return I received a phone call from that island.  I don't recall if it was the very next day or not, but it was definitely within a week.  Whomever or whatever targeted me had coincidence on their side for sure.  I did not return the call before asking him if he had given my number to the person he had left behind.  When he said he did not, I knew to ignore the call.  There was no reason anyone from Aruba, Grenada, or any other island should be calling me.  Turns out that shortly thereafter I got wind of this scam.

Building Security In

Let's take a second to talk about development.  For most of us there will become a point in our careers that we will have to work on some type of development project.  For some development may be a career, while for others it is just part of the journey of professional growth.  The model by which you develop may be different in each position you hold - waterfall, spiral, extreme programming, agile, and any other rad types that didn't make the cut for this post.


Security in development models has only truly become a concern recently; probably about the past 10 years or so with a major emphasis in secure coding for probably the past 3-5 years.  I'm not necessarily saying that security was never there, certainly early developers had it in mind or operating systems wouldn't follow the model of separation shown between applications, high-level drivers, low-level drivers, supervisory layer, and the kernel; dacl's and rbac wouldn't exist, and so on.  My only real point here is that it is only recently that security early in development has become a focus instead of an after-thought, and after so many people have been developing for so long without it as a major concern. 


So it should come as no surprise then that convincing developers to build security in is a tough feat to accomplish. 

The Importance of Policy

The very first blog entry starts with policy, because...well, everything starts with policy really.

I once interviewed for a job a ways back; a real career move into one of those important positions.  I didn't get it, but things were going as they should, when I get a fairly standard question.

To paraphrase:

"Let's say you are evaluating a new program.  You have identified several policy violations during your review (I noted they were careful not to say audit).  When you approach the project manager he says that he will not address whatever controls you found were lacking.  How do you get him to do it?"