SecurityZone – to finish this year with a bang!

So, some of you have heard of SecurityZone, some are skeptical and some just jealous. Here’s the gist of it from my view:

Professional:

  • Awesome lineup. We managed (and I allow myself to say we as I might have had some help with getting some of the speakers) to get some of the coolest names in the industry with cutting edge security content. To think that this is a first time conference, I would have cut off a kidney to get a lineup like that. Yet it’s on!
  • Workshops – I’m super excited to be part of the workshops. For some reason (don’t ask me how) the notorious Chris Nickerson and yours truly will have a chance to basically go all-out on a red-team testing workshop. I cannot guarantee the sanity of participants at the end of the day, but I’ll be damned if they won’t at least enjoy it. Subtle hint – buy us drinks and more fun is guaranteed ;-) . Now take a look at the other workshops. I know… tough choice!

Venue:

  • Come on, it’s Cali, Colombia! What can go wrong in a city that calls itself the capital of Salsa. That sits in one of the more beautiful places in northern south America, and that brings the warmth and hospitality of the locals to tourism. Haven’t been there yet, and I’m already sold – just based on reading some online, working with the relentless SecurityZone organizers (huge shout-outs!), and talking to people who already visited the place.

Personal:

  • My roots actually go back to south america. My dad managed to visit Argentine just this year for the first time since he was a kid, and for me an opportunity to get a little closer to the culture was something I just couldn’t pass on…
So, bottom line – this looks like just the perfect grand finale to an awesome year of the Dirty Security World Tour 2011. Very excited to meet everyone from the crew, and especially to meet new people – locals and whoever makes the smart choice and picks this as an international security conference to attend.
Ciao!

Information Security, Homeland Security, and finding someone to pin it on

In the recent spree of cyber attacks on a plethora of US and international government and federal related establishments a lot of speculations are being thrown around as authorities are trying to find the threat community behind it.

As computer systems are reigning most of the control over our daily lives – from transportation, through financial systems, and up to government facilities that provide research, analysis and even critical infrastructure to support what we know of now as “modern life”, attackers find it easier and easier to poke at such systems as their security is left mostly as an afterthought. Most of the focus when the relevant organizations approach the forensics and remediation of such breaches is first to recover any lost data, and then to identify not the root cause of the breach, but the attacker.

As the blame game runs amok, the actual privacy and confidentiality of the core (digital) elements of our modern society are left for grabs. When groups such as LulzSec, Anonymous, and any other book-reading internet-browsing anonymous-under-several-proxies infosec-warrior find it as easy as running a few scripted tools on their target list to find easy to exploit issues, we are facing a very tough job of figuring out who to blame.

Nevertheless, blame by itself (or attribution as we like to refer to it in the more politically-correct industry circles) won’t help us in mitigating such attacks. It may be helpful for organizations to have someone to pin the “adversary” tag on – especially when dealing with defense/government/federal institutions who’s budgets can be manipulated more easily under the threat of a foreign nation. But when looking at the ability to actually come up with evidence to support such claims we often face empty hands, and a thick smokescreen of assumptions, prejudice, and incompetence.

On the other hand, when viewed from a strategic/political stance, it can be easily seen how a string of breaches in facilities that share a common ground (such as the one presented by Rafal Los of HP in his great article “DOE Network Under Siege”) can be attributed more to a nation state than to a fun-seeking internet-bored group.

This simple reality – of having intricate connections that are often only visible when looking at the bigger picture of security incidents, allows state sponsored attacks to happen without much scrutiny or the ability to thwart them on a more strategic position.

The bottom line remains the same – chasing after excuses and online enemies won’t get us to a more secure state. Investing in proper education, training, exercises, people and (lastly) technologies, will. Instead of trying to investigate breaches from an attribution standpoint, we should be investigating root causes to the deepest level (i.e. not stopping at “a 0-day vulnerability we didn’t know of”, or the bit-bucket of “It’s an APT”) that involves how we manage our electronic infrastructure and how we keep track of what’s going on in it after the initial setup is complete and the contractors/integrators pack up their people and leave.

Post Brucon thoughts – guesstimates in an engineering field

So, another epic Brucon has ended, and while everyone is getting their thoughts together again (the amount of super smart people I have had the pleasure to have conversations with is unimaginable), I wanted to post a quick recap.

First things first – numbers. I’ve been working with the FAIR methodology quite a while now, and have actually (with the kind permission of Jack Jones) integrated some of its elements into the Penetration Testing Execution Standard (PTES). Watching the discussions that started after Jack’s talk at Brucon was heartwarming. Pentesters and security practitioners finally “get it”, was divine. Working in a field of engineering that has the least engineering in the sense of how it’s applied to businesses has been frustrating to say the least. With the ability to effortlessly connect the technical elements of vulnerabilities and exploits to business-speak has been one of my personal challenges (and hopefully strengths), and being able to tilt the industry even a little towards that direction is something that we all needed for a long time.

A quick “teaser” to add on top of it (which has been previewed in my talk) is the ability to also marry in the social media risk into the risk management practice (look out for some more cool research and insights coming from that direction very soon!).

Which leads me to the last point – the ever evolving presentation I use to deliver the message about data exfiltration is provided for your viewing pleasure. Don’t fear the >100 slide count – it’s mostly the “build” effects that I left in for clarity.

Looking forward for some more discussions and developments in the way that we as an industry are justifying what we practice (if it wasn’t obvious by now – go check out what FAIR is, and then start thinking on how to integrate it into what you do…).

7 Steps to consider when running a Vulnerability Assessment

Today I’m proud to give this stage to some friends from GFI (have some good friends from the former Sunbelt guys that were acquired by GFI last year). Vanessa is our guest blogger, and she’s got a great post on how to run a more effective Vulnerability Assessment process in your organization.

 

Do you know how your server measures up to potential threats? If you haven’t performed a vulnerability assessment on your servers yet, you may not be aware of issues that may leave you exposed to hackers and web-based attacks. A vulnerability assessment is the process of inventorying systems to check for possible security problems, and is an important part of system management and administration.

Vulnerabilities are weaknesses within a server or network that can be exploited in order to gain unauthorized access to a system, usually with the intention of performing malicious activities. The most common way to address many software-related vulnerabilities is through patches, which will usually be provided by the software manufacturer to correct security weaknesses or other bugs within an program. However, there may be times when a patch is not available to address a possible security hole, and not all vulnerabilities are software-related for which a patch would be offered. This is where the concept of vulnerability assessment comes into play. Minimizing the attack surface and the effect that a potential hacking attempt could have on your system is a proactive way of effectively managing a server network.

While there is no 100% way to protect your servers against vulnerabilities, in performing a vulnerability assessment there are some steps you can take to minimize your risk:

  1. Close unused ports
    Ideally, your server network setup should include at least a network firewall and a server-level firewall to block undesired traffic. Undesired traffic would include traffic to ports that are unused or that correspond with services that shouldn’t be publicly-available. These ports should be blocked in your firewall(s).
  2. Don’t over-share
    If servers on your network are set up to share files with others, or to access network shares (such as file servers and other resources), make sure that those shares are configured to only allow access as appropriate. Hosts that don’t participate in sharing resources should have that capability turned off completely.
  3. Stop unnecessary service
    The more services you have on your server, especially those that listen on network ports, the more avenues a hacker has to get into your system. This is especially true if you have services running that aren’t being monitored or used, and therefore are unmaintained. Stop services that are not in use or necessary, and restrict access to others that are not intended for public access.
  4. Remove unnecessary applications
    Many operating systems come with a wide set of programs that may not be necessary for normal server operations. Find out what software is installed on your system, and then determine which of those applications are not necessary and remove them.
  5. Change your passwords
    Using default vendor passwords is more common than you may think – but since those passwords are usually publicly-known, they are often the first ones used during hacking attempts. Secure passwords should always be used in favor of the vendor defaults, and industry experts recommend changing them every 30-60 days.
  6. Do some research
    When software or new applications are installed, users often neglect to take the time required to review their settings to ensure that everything is up to par with modern security standards. Take some time to research what you are installing and any security implications that it may have, including what features may be enabled that could introduce security problems, and what settings need to be adjusted.
  7. Encrypt when possible
    Many services and network hardware have the capability of encrypting traffic, which decreases the likelihood of information being “sniffed” out of your network. When transmitting sensitive data, such as passwords, always use an encrypted connection.

Regular vulnerability assessment is a vital part of maintaining system security. Not only will it help diminish the success or possible effects of malicious activity against your servers, but it’s also a requirement for many compliance standards such as PCI DSS, HIPAA, SOX, GLB/GLBA, among others.

This guest post was provided by Vanessa Vasile on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. More information on vulnerability assessment

All product and company names herein may be trademarks of their respective owners.

 

Upcoming conferences schedule: August-November 2011

So, as if I didn’t have enough flights this year, here is where you can find me and hang out / grab a beer / talk shop / hack:

August

BSidesLV (August 3-4). If you are in Vegas in August, this is THE place to be. I’ll be running a couple of talks there – one with my colleague Itzik Kotler on VoIP botnets, and another on advanced data exfiltration. I’ll also be on the PTES panel, and will help out with the conference security.

DefCon (August 5-7). I’ll also be presenting at DefCon with Itzik on VoiP botnets.

September

Brucon (September 19-20). Seriously one of the best cons out there. And you get to enjoy the Belgian beer. What can go wrong? :-)

October

Hashdays (October 26-29). First time for me at this conference. Friends who attended in the past can barely be reached for comments. This year’s badge will blow away any badge you have ever seen in a con. Oh, and the lineup is sick!

November

GovCERT.NL symposium (November 15-16). This is one of the best CERT teams I have had a chance to know (people-wise as well as professionally), and I’m really excited to have a chance to work with them again on some of the more burning issues in national level security.

SecurityZone (November 28-30). Finally – Latin America. Again – my first time at this conference. Looking at the speaker lineup this should be really fun, and the opportunity to mix in with the local Colombian security scene should be terrific!

Bottom line – really excited to have a chance to attend and speak at all these cool conferences. This year’s con selection has been focused on events that I’m familiar with and know are really good, and some new events with people I know and trust to run a top-notch conference (a policy that haven’t failed me yet…).

See you around!