als, bls, cissp

Those of you who have the misfortune to know me personally know that information security is but one piece of the pie that is Al Berg.  (mmmm…. pie…)  On Friday nights, I swap my desk for an ambulance of the Weehawken Volunteer First Aid Squad where I am an Emergency Medical Technician.  Most of the time, these two parts of my life don’t really intersect, but this week, I saw something that seems to bridge the gap.

So, there are two different kinds of ambulances here in the US.  BLS (Basic Life Support) rigs are staffed by EMTs who are trained in basic life support techniques focused on airway, breathing and circulation.  EMTs do not administer drugs – we cannot even give you a Tylenol for pain.  If you are unfortunate enough to be meeting us on a day when you are having a cardiac arrest, we will do CPR, give you oxygen and maybe zap you with a automated defibrillator.  We’ll also call for our ALS (Advanced Life Support) colleagues – the paramedics – to respond and give you the advanced monitoring and interventions (EKG, intubation, intravenous drugs, and the like) that we can’t.

As an EMT, I am always happy to have paramedics on any call, especially a cardiac arrest, so I was really surprised to read an article this week which described a study published in the Journal of the American Medical Association which found:

90 days after hospitalization, patients treated in BLS ambulances were 50 percent more likely to survive than their counterparts treated with ALS. The basic version was also “associated with better neurological functioning among hospitalized patients, with fewer incidents of coma, vegetative state or brain trauma.”

Now, to be clear, your chances of surviving an out of hospital cardiac arrest are pretty lousy… 9 out of 10 patients who ‘code’ in the field will not survive to hospital discharge.  CPR works way better on TV than it does in real life.

Anyway, while I am a bit skeptical of this study’s results, it does seem to me that there is a bit of an information security aspect to this.  Time and again we hear of companies who have spent big on flashy technology still getting owned by hackers.  For example, Target had purchased advanced anti malware defenses from FireEye as well as outsourced monitoring for those defenses.  According to reports, the people and tech detected the bad guys, but failing to do “information security BLS” by examining the systems which were showing signs of trouble sealed Target’s place on the front page.

There are a lot of “information security BLS” measures that don’t use flashy technology or wheelbarrows of money that we can take to protect our systems:

  • Documented policies and procedures
  • Least privilege for user accounts
  • Segmentation of internal networks
  • Applying security patches and updates in a timely fashion
  • Security awareness training
  • Sharing information with other organizations

These (and many other) “information security BLS” interventions go a long way towards keeping hackers away from corporate data.  They aren’t complicated, and you don’t need to buy all sorts of blinkie light boxes to implement them.  Yet, time and again, companies fail to pay enough attention to them.  Part of the problem is that infosec professionals want to get hands on with the latest technology and doing some of these low tech interventions requires serious time and planning to avoid negative impacts to the business.

So, my resolution for 2015 is to take another look at the Council on CyberSecurity’s Critical Security Controls list and make sure my organization is doing everything we can to implement them.   As an industry we need to make sure we are doing the BLS interventions right and apply the ALS level security-fu when it is needed.

als, bls, cissp

quick and dirty malware analysis

There are a number of web based tools that allow you to safely analyze the behavior of potentially malicious files safely.  My personal favorite is Malwr.com, which provides detailed analysis of just what a piece of malware tries to do when run in a sandboxed environment.  Malwr presents its findings as a detailed report explaining what processes are spawned, what files and registry keys are written and what network activity happens when the malware runs.  This is a great tool for those of us whose budgets don’t include funds for maintaining our own malware analysis labs.   For those with some more resources, you can run the same software that malwr.com uses (the open source Cuckoo malware analysis suite) on your own site.

I recently saw a video from Security BSides DC 2014 in which Craig Fields, a malware/forensics analyst from DefensePoint, demonstrated a new tool to make reading reports generated by malwr.com easier.  MalwareViz takes the URL of a malwr.com report and uses the data in the report to create a more visually oriented diagram of just what a particular piece of malware is doing, which can be really useful in explaining things to non security focused folks.

It is important to remember that malware authors are getting smarter and smarter – in some cases, malware will check to see if it is being run in a sandboxed virtual machine.  If so, the malware stops executing and the analysis doesn’t see the bad behavior which will occur during a real infection.   So, a negative result from the sandbox is just one (albeit generally a strong) indicator of whether a particular file is malicious.

 

 

quick and dirty malware analysis

insecure systems? no insurance for you!

It seems that car thieves have been targeting the keyless entry systems of high end vehicles, taking advantage of insecure security in their on board computers.  In addition to stolen cars, this has also caused some insurers in the UK to refuse coverage for certain models of Range Rovers in London unless their owners take additional security measures.  This is an interesting development – if your potential customers can’t get insurance coverage because your car (or other device’s) computer enabled systems aren’t secure, then you have a real incentive to fix the problem.   Now how do we apply this to other types of systems?

insecure systems? no insurance for you!

racing the patch clock

all too true, usually

When previously undisclosed vulnerabilities in the Drupal web content management system used by many large companies to manage their web sites were announced, hackers were busy exploiting those weaknesses within hours.  This incident highlights the bind that security people and system administrators are increasingly find themselves in – we need to patch critical vulnerabilities quickly to protect our systems from compromise, but rolling patches out without proper testing can also lead to downtime (witness Microsoft’s recent run of faulty security patches).    Having the skills to mitigate vulnerabilities while patches are tested and rolled out is a something we need to cultivate as security pros.

racing the patch clock