Pratum Blog

Breach investigations are by their nature somewhat chaotic. There is a flurry of activity by the HR, IT, Legal, Communications and line of business departments. The ability to quickly determine what happened, who or what was impacted and what the next steps are can be thwarted by a lack of information. Logs are critical in helping understand all aspects of a breach.

In the past we have talked about the importance of logs from firewalls, routers and layer 3 switches, server or workstation event logs and intrusion detection logs. Two logs which are commonly overlooked are DNS and DHCP logs.

At 2am in the morning it is much easier to simply pull up a DHCP log and determine that machine HQ5678A was assigned 10.1.25.163 on 03/03/2015 at 9:53am rather than having to query registry entries or sift through event logs hoping to find a trace.  It is also helpful if systems hold their DHCP leases for 30 days or longer. It keeps the logs shorter and helps investigators more easily spot trends of activity, whether that be normal or abnormal activity.

It is also easier to have firewalls record DNS entries and have the log contain both an IP address along with a DNS entry so you can quickly tell that a user on computer HQ5678A was using ebay on port 443 versus a virus using port 443 to communicate with hackme dot com that same port. Much time is spent tracking an IP address to a hostname simply to discover that the communication is to or from a known and approved host.

Time is something you have precious little of during a cyber-security or breach investigation. Taking action before the security investigation begins can save you a lot of time and keep you from running down rabbit trails during your investigation.

If you are a small community bank and someone is offering to do network level penetration testing for 1 or 2 firewalls for $1,500, that’s a reasonable bid. If however, you have a load balanced web application running on 3 or 4 front end servers, 4 application servers and a database cluster with multiple user roles, the costs should be much, much higher.

The first thing to remember is that vulnerability scanning is all automated. Don’t let someone sell you a vulnerability scan as a penetration test. Ethical hacking or penetration testing, is largely a manual process. If during your vendor evaluation a vendor says a penetration test is going to take 5 days but only charges $2,000, a red flag should go up. How is that possible? That’s not much more than Geek Squad rates. Nothing against Geek Squad but they are hardly business class IT support, much less information security experts.

If this is truly penetration testing, these costs should be much higher. Ask the vendor to explain their testing process. How much is automated vs manual. Ask what certifications they have that are specific to penetration testing. I’ll be frank with you. I’m a Certified Information Systems Security Professional (CISSP) with 20 years of experience and our team of penetration testers at Pratum that have the Certified Ethical Hacker (CEH) or GIAC Penetration Tester (GPEN) certifications can run circles around me in this area of information security.

The last thing you want is to base your assurance of information security on a faulty penetration test. Take some time and ask questions. Compare the answers from multiple vendors. Contact a local ISSA chapter and ask someone there to give the quotes a quick glance for you. There is a lot of confusion in the market place about this topic so make sure to do that extra bit of due diligence to ensure your money is being well spent.

I’m going to state this very bluntly. No server needs internet access. Do I have your attention? Good. Now let me clarify. The vast majority of servers should never be allowed to make a connection to the internet. This goes double for database servers. If you want to ensure information security and protect against a data breach keep reading.

Now, I’m not talking about severs in your DMZ which are used to provide public facing services or provide DNS or email. I’m talking your internal file and print, Active Directory domain controllers, CRM, ERP, etc. If these servers need an update, get it from a single purpose update server in a different security zone.

One of the common problems we see during a data breach investigation is that a server is compromised and then used to funnel information back out. If this server was in a security zone with egress filtering, alarms would trigger the instant any outbound communication attempt was made giving the information security team a chance to detect the anomaly and respond accordingly. A serious data breach may have been prevented.

I’d encourage you to do an inventory of the internet access rules of every server in your organization. Ask yourself is this is necessary? Could the services be accessed or routed through other devices? DNS and NTP are common examples. Servers should only get DNS or NTP from an internal source. There are too many attack vectors using those protocols. If servers do need internet access, they should be put in a separate security zone which is less trusted that the other zones. Consider it an internal DMZ if you will.

Information security is hard. There are a million different ways the bad guys can get you and cause a data breach. Let’s not make their lives any easier but throwing them a lob pitch and letting them swing for the fence.

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.