HD Moore's Law? How can you tell if you are compliant?

HD Moore's Law is a joke. And not a very funny one either being a pun and having a requirement of being very technical and requiring knowledge of the IT Security community just to get half way to understanding it. It usually requires the user of the term to explain why it is funny and that is a serious faux pas when it comes to jokes.

So, let me explain the joke. :)

Moore's Law is pretty well known. The majority of people know it as "computers will get faster each year" which is close enough to the actual definition as to be useful for making decisions such as "I don't need a PC right now, should I wait a bit?" The answer is "yes, if you wait then for the same amount of money you will spend now, in the future you can get a more powerful PC." Moore's Law.

(The actual law itself was coined by Gordon E. Moore from Intel who predicted that the number of transistors on a chip would double every 2 years.)

HD Moore created MetaSploit which is a framework for creating and running exploits. Being a framework, it is as clever as the person using it and can be used to break into anything with enough time and patience and understanding. However, it can also be used by someone with minimal knowledge and understanding to quickly break into a badly protected system.

This really divides attackers into two camps - dedicated and opportunistic. The controls to protect against both of them are very different but initially an organisation should be protected at the very least against opportunistic attackers. This is HD Moore's Law.

But the exploits available on Metasploit are always changing and the systems that can be attacked are expanding. There are modules available to attack PHP. This means that PHP falls into the "opportunistic" area of HD Moore's Law.

My question...finally....is this....

What level of patch does each and every type of software have to be at to avoid falling foul of HD Moore's Law?

Does anyone know?

Because, jokes aside, (and it wasn't a particularly good one to start with) knowing that an organisation is not at risk from opportunistic attacks would be useful  - more so than knowing ISO compliance or that staff are deleted off the system within .578 microseconds of leaving the organisation.

Then more dedicated attackers can be targeted using the controls aimed at them.

Seven Habits of Highly Effective Security Plans [Part 6]

Habit 4 is the first habit to deal with “others”. The first 3 habits are internal – 4 is external.

Think “Win-win”. This is almost impossible for a security professional. Almost.

The issue is that every change to a system (from a lonely PC to a worldwide network) has some risk to the system itself and mostly in terms of availability. In some cases the risk is 100% - for example when a system needs to be rebooted after a patch is applied or even when a service needs to be restarted. It may be a quick reboot and it may be done during a patch window but either way someone needs to sit, sweating and biting their nails, while the box goes through the motions of starting up. In some cases the order that Servers are restarted is important.

I have been attending many job interviews recently and they one question that comes up very often, (and for good reason) is: how do I (Allen specifically) manage teams where there is no will to perform security tasks. It is not easy; security generally does not get given the correct amount of authority to demand that the security tasks get carried out. Nor does the security team generally perform the tasks that are required to keep the organisation secure. Compliance does help (“The auditors are not going to be happy. “) but this sounds like a winey way to get force administrators to perform the security tasks and since Audits are usually annual the Servers tend to be fully compliant once a year at audit time.

Generally, you need buy-in. The easiest way to do this is to live the values yourself. Is it really necessary to patch? Really? All the servers? What if we leave out a couple, maybe the production machines which are all running an older version of Windows? If you don’t have good answers to all of these questions. And by that I mean *good* answers then how do you expect to be taken seriously? The thing I really like about the habits is that they all make sense but more importantly they make sense together. So understanding why you do something is a totally different habit. (Habit one.) Mastering that habit makes you surer of yourself when faced with these questions. It makes it easier to bring the people that count (in this case, the Administrators) around to be on your side.

Once you have buy-in from the Administrators (and their managers) you should approach them to come up with a viable (and practical) plan for performing their tasks. The amazing thing is how much better this works when it has been created by both the security team and the services team (or whoever is going to perform the security task.) When the team knows upfront what is expected and when and can put the methods in place without surprises and has the backing of the security then the processes just flow.

Another place where this habit is important is combatting the idea of the “Dr No. Security Guy”. The idea of this is that Security should not ever be the guy to say “no” to a project or idea without fully thinking it through and trying to arrive at a win-win outcome. It should be a project that is useful to the business, not too expensive to implement and as secure as necessary. A good way of approaching a project that you believe would be too insecure is to start with “I agree that this may be a good idea for the business but I believe that the controls we would need to implement to secure this solution would make it too expensive for any benefits.” You then show what these controls should be and leave it up to the project sponsor to make a decision. Sometimes a project decision made with no thought like “we want it to be a PaaS solution” can be reversed when the security controls are included in the final design without scapping the entire project. Example:

“We want the new solution to be PAAS”

“Why?”

“Because that is our project parameter”

“Um…ok…there are a few things we will need to implement though.”

“Like?”

“Well, for network security we will need to put in a Firewall and IPS and something to monitor them and collect the logs. We will need to do application security since this faces the entire world. We will need to set up someone to monitor all of the equipment. We will need to arrange with the service provider some time to do patching and general maintenance. We will need to do a physical security audit. We will need to have a monthly meeting with the service provider to discuss security controls. The Audit team will need to add this to their annual audit. Plus we will need to investigate the increase in bandwidth costs for us to be able to access the solution. After all that we may need to look at DR and BCP depending on the criticality of this solution.”

-Pause-

“What is the alternative?”

“We host it inside our network where all the infrastructure is already in place and monitored and you have to pay very little for additional security infrastructure. If it helps, we can host it on a virtual machine and you can call it ‘private cloud’”

Win-win.

Seven Habits of Highly Effective Security Plans [Part 5]

Steven R Covey died on July 16, 2012. This is sad news indeed. I really liked his 7 habits work. It was (like ISO27002 and the like) a good framework but not a good standard. And therein lies its power. It is like powered milk – without adding something then you have nothing. I took the 7 habits and started (5 years ago!) to make a series called the 7 habits of highly effective security policies.

I got stuck at habit 3. I honestly have tried over the last 5 years to write a blog post that is acceptable to my standards on habit 3 but now that I reflect on it, it’s a good thing that this one is the most difficult. It is also the one that everyone should define for themselves. I believe this is the core habit and while the other habits are easy to adopt with practice, this one needs to be revisited often. It can’t become a habit. So, I am leaving this one out for the readers to do for themselves.

The only advice I can offer here is that as a security professional you will always have something urgent to deal with. You will always be reacting to the latest exploit in the news, the latest report from the auditors, the latest breach. There are new virus definitions every day and new patches every month. You are always reacting. You have to set some time aside for proactive security. For acting. How you do that is up to you but it has to happen.

I may revisit habit 3 in future but for now that is all you get…

Moving along…habit 4.