Developing Security

Why aren't cloud services secured as a service?

Below is an excerpt from my first (hopefully not last) post for the Cloud Security Blog by Trend Micro:

---

Cloud-based security as a service offerings have seen a steady increase in popularity, due to the benefits that the deployment model provides. Security as a service enables rapid provisioning, cost savings and enhanced security through real-time updates and the community effect.

With the explosive adoption of public cloud computing it's time we apply the techniques used to provide security FROM the cloud, to provide security FOR the cloud.

In public cloud environments like Amazon Web Services (AWS), the Elastic Compute Cloud (EC2) instances only provide firewall as a service. It’s up to the customer to harden the operating system and the applications running within the virtual machine instance. Ongoing patching helps reduce the attack surface, however patching alone doesn’t maintain a secure environment. The only currently viable option to augment the security posture is host-based controls deployed and managed by the customer. Host-based agents can provide Anti-Malware, IDS/IPS, WAF, DLP, Integrity Monitoring and other capabilities, but it’s up to the end-user to purchase, deploy, configure and monitor these countermeasures.

This presents an opportunity for service providers to offer security as a service, designed to protect the instances their users spin up. With the introduction of premium pay-per-use security services, customers could choose the countermeasures they require on a feature by feature basis. Adding malware scanning of your virtual machines could be a single check box away.

Read the rest...

Crossing the Border - JavaScript Exploits

Recently I had the pleasure of giving an OWASP presentation on JavaScript Exploits. I had some fun with the talk and compared countermeasures used to prevent JavaScript Exploits to Chinese border security.



I really appreciate all of the people who came out both in Ottawa and Montréal, and the feedback I received was really positive. A special thanks to the chapter leaders for making this possible.



If you are interested in giving a presentation to either of these OWASP chapters, they are always looking for volunteers. More information can be found on the Ottawa OWASP or Montréal OWASP pages.



Download the PDF (3.3 MB) or view the slides below (if your reader supports iframes).

3.2 KB of Code Can Kill You

A colleague of mine, Karthik Krishnamoorthy, forwarded me a link comparing H1N1 to a computer virus. The post is the most fascinating description of the inner workings of a virus I have ever read and does an excellent job of translating the biology of a real virus into computer terms more understandable by us in the information security industry.

For Example: "If you thought of organisms as computers with IP addresses, each functional group of cells in the organism would be listening to the environment through its own active port. So, as port 25 maps specifically to SMTP services on a computer, port H1 maps specifically to the windpipe region on a human. Interestingly, the same port H1 maps to the intestinal tract on a bird."

The article shows how real viruses have the equivalent of polymorphism and NOP sleds, and most worryingly how efficient they are.

"So it takes about 25 kilobits — 3.2 kbytes — of data to code for a virus that has a non-trivial chance of killing a human. This is more efficient than a computer virus, such as MyDoom, which rings in at around 22 kbytes. It’s humbling that I could be killed by 3.2kbytes of genetic data. Then again, with 850 Mbytes of data in my genome, there’s bound to be an exploit or two."

The article goes on to talk about how the virus mutates and adapts to the environment despite its relatively small amount of 'disk space'.

The article can be found here.

Speeding on the Information Superhighway

After narrowly avoiding a speeding ticket recently I realized, there is a lot of similarity between data security and the risks of the open road.

We all know that the role of information security is to reduce risk to an acceptable level, however sometimes the reason for existence of the risk in the first place is ignored...the reward.

The reward of digital information exchange is increased productivity, lower costs and improved service. A bank that didn't offer online banking would be far more secure, but it would hardly be competitive or cost effective.

The more services that move online, the faster business is conducted, the more risk we take on. With all of the data breaches going on lately, are businesses speeding?

Speeding on the real highway is risky business. The risks we face in driving are similar to the risks we face in business:

• The risk of getting a ticket - The risk of getting fined for failing an audit
• The risk of loosing points - The risk to your reputation for having a breach
• The risk of crashing - The risk of data loss
• I think you get the point...

Balancing the risk vs. reward can often be a difficult task. Sometimes we have a distorted perception of the risk we are getting ourselves into (like when I let my wife cut my hair). The reward too is hard to judge. Opening access to your database for a partner may seem like a good way to integrate quickly, but you'll soon regret it when they plug an application with SQL injection into it!

In cars, like datacenters, we adjust the risk/reward ratio by using countermeasures:

• Airbags/Crumple Zones - Raid, WAF, AV, etc.
• Radar Detectors - IDS/IPS (Yes, I realize that I'm mixing the good guy/bad guy)
• Car Insurance - Disaster Recovery
• And so on..

Recently I heard of an insurance company where you pay based on usage. They plug a device into your car and charge more if you are driving above the legal limit or at risky hours. Privacy concerns aside, I think this is an interesting way of having the risk/reward balance encouraged. If you knew that actions you were taking would have personal, and very real, repercussions you may defer risky options in favor of options that keeps your business more secure.

Without some form of auditability and accountability, right now it's up to each organization to decide how fast they want to go, and some may be going faster than they can handle. 

5 things you might not know about Justin Foster

The chain letter... What was once the realm of Facebook or Email has made its way to the blogosphere by way of Andrew Hay. Andrew has tagged (or rather challenged) 5 other bloggers to reveal 5 things about themselves.

I can honestly say, I have NEVER participated in an email chain or answered anything where I have been tagged in Facebook, but I'll accept Andrew's challenge (because he's pushy).

From Andrew's Post, here are the rules:

1. Create a blog post with the title “5 Things You Might Not Know About YOURNAME” (where YOURNAME is your first and last name).
2. List 5 things that people may or may not know about you (it can be anything really).
3. “Tag” 5 other people to do the same via the blog post, twitter, facebook, or all of the above.
4. See what happens.

So here are my 'things':

1. I started programming at age 6, but it took a failed attempt to become a pilot before I realized that It was something I could make a living at
2. I haven't had a job interview since 2000 despite working for 5 differently named companies. The last 3 were through a series of acquisitions starting from a 2 person company to the current 4000+!
3. Outside of work I spend more than 10 hours a week on security, leading some to question my sanity (and my judgment)
4. I'm hyper security conscious (others would say paranoid). I once rotated over 100 unique passwords after a bad dream (It was something about being pwnd hard like Dan Kaminski in ZF05) :)
5. Prior to this year I was intensely private and wouldn't dream of engaging in 'Social Media', but the opportunities that have opened up because of Blogging, Twitter and Facebook are well worth the effort

bonus answer: I'm now guilty of 6 things on my Top 10 Signs you are a Security Twit list.

As per Andrew's Rules, I'll tag 5 people. However, unlike Erin Jacobs (SecBarbie) who has already responded to Andrew's challenge here, I'm picking people I think are likely to NOT participate: Ben Tomhave, Chris Hoff, Amrit Williams, Jack Daniel, and Rafal Los.