Perfect Forward Secrecy

What is perfect forward secrecy?

In cryptography, Perfect Forward Secrecy is a property of key-agreement protocols that ensures that a session key derived from a set of long-term keys will not be compromised if one of the long-term keys is compromised in the future.

Thus, if your webserver is hacked and the server’s keys compromised, the possession of these keys does not allow the attacked to decrypt prior communications sessions which may have been captured in transit.

When Perfect forward Secrecy is used, both parties to a communication session generate session keys on the fly, and only the two parties have access to the keys.  No one else can, even if they have access to the server's private key determine what the session keys were, and thus decrypt the session if it was captured in transit.

After the session is complete both parties destroy the session keys. The only way to decrypt the communication for the session is to brute force hack the session keys themselves, and breaking strong session keys is clearly much more difficult than obtaining a servers' private keys. Also bear in mind that each session will have different session keys so this makes an attackers job exponentially more time and resource intensive.

Which cipher suites are supported?

SSL supports Perfect Forward Secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE).   

Why isn't everyone using them, then?

Assuming the interest and knowledge to deploy forward secrecy is there, two obstacles remain:

• DHE is significantly slower. For this reason, web site operators tend to disable all DHE suites in order to achieve better performance. In recent years, we've seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys.
• ECDHE too is slower, but not as much as DHE. (Vincent Bernat published a blog post about the impact of ECDHE on performance. Might have changed since 2011.)

The below graph from the blog post shows performance for 1000 handshakes of various cipher suites (RSA 2048, DHE, ECDHE, optimized ECDHE)

Support for clients

If you're willing to support both ECDHE and DHE, then you will probably be able to support Perfect Forward Secrecy with virtually all clients. But ECDHE alone is supported by all major modern browsers, which means that even with only ECDHE you might be able to cover a very large chunk of your user base. The decision what to do is entirely up to you. Google, for example, do not support any DHE suites on their main web sites.

Conclusion

If the performance hit is acceptable, sites should use Perfect Forward Secrecy as an extra layer of protection against server key compromises.

It security On the cheap

There are a  lot of people or there with a lot of opinions on fancy and expensive security tools which they beleive are required to ensure network security.

It is my opinion that a lot can be done to ensure a secure network with free and open source tools.

Spiceworks cans be installed on a spare pc and perform inventory and patch analysis.   Spiceworks.com

Trisul us a software package that runs on Linux and can monitor network traffic.
Trisul.org

Untangle can be installed on a system to provide a enterprise grade firewall.
Untangle.com

And Microsoft Security essentials us a free anti-virus software from Microsoft

While you can spend thousands to millions on commercial software an support,  there are open source and free alternatives.

Russ Dyer. CISSP CRISC
Security Analyst and Mobile Device Evangelist

DLP not a Golden Bullet

Realized the other day that buying a dedicated DLP solution is not better than using other tools and doing behavioral analysis of  users. We should be alerting on resume and job site access and correlating that against travel site access to try to identify users who are contemplating resigning.  Then monitoring those users for after hours file acces and large traffic volumes on the network. All this can be done without a Dedicated DLP solution.

New Nexus 7

The new Google Nexus 7 us a powerhouse pocket able android tablet that's a steal at 229 dollars.

http://www.google.com/nexus/7/

It's on my wishlist of gadgets for the mobile geek.

Catcher in the Rye

Information Security goes on the Offensive

By S. Russell Dyer BS(MIS) CISSP CRISC

Prologue

It is well documented that the man who shot John Lennon, JFK’s assassin,  and the guy who shot Ronald Reagan all had a copy of the book “Cather in the Rye”.

What if we could identify malicious hackers  by their common access to a single file, or group of files?

Information Security is a constant game of cat and mouse. Unfortunately,  the good guys are frequently one step behind the bad guys.  Hackers discover a security flaw in a particular software and begin exploiting it and eventually Security practitioners detect and classify the activity as malicious. Then with the help of developers either patch the flaw or apply new methods or tools to mitigate the security issue. Then the cycle repeats in a never-ending circle.

Perhaps we can shift this paradigm in favour of the good guys. Or even turn it upside down entirely where the hackers are the ones trying to catch up and figure out what is safe for them to touch and what is not?

Background

Firstly, we must understand the typical process a hack follows and match this process to the attacker’s high level goals.

For a hacker to be successful he, or she, will undertake the following tasks.

1. Exploit a software or configuration flaw to gain access to a host system.
2. Make changes to ensure access survives a reboot of the system.
3. Hide any traces of activity to enable longevity of access.

Once these three objectives are accomplished, the hacker can start poking around and looking for valuable information. Also, using this compromised system as a pivot point to move deeper into the network and compromises more valuable hosts.

Flipping the Paradigm

While we endeavor to have all our network assets and infrastructure patched and secured, there will always be one or two systems which slip through the cracks. Whether it’s a server running an older operating system that’s due to be replaced in the near future, or an application running on a server which isn’t quite on the latest patched version. There will be cracks and these will be exploited in an attack.

Honeypots have been around for a while and are an ok system to use in an attempt to entice and detect hacking activity; they rely on the hacker focusing on the honeypot,  and activity on that honey pot server being used and an indicator that there has been a security breach. But there is no way to guarantee that an attacker will target the honeypot and not a different, more important system.

I propose a new take on the honeypot, the Honey file.

Honey files can be placed on each system and monitored at a heightened level to serve as an alarm and strong indication that the system has been compromised by an attack.

The honey file is a specially created file which meets the following criteria.

1. Not accessed or used by the host hardware, operating system or any installed applications on the system on which is resides. (Thus any accesses or changes to the file can be assumed to be either accidental maintenance related or malicious hacker activity)
2. Must not contain any information that would be of actual value to an attacker.
3. Any alterations, additions or event complete removal of this file must in no way affect the host system or application in any way.
4. This file may contain authentic looking but fake information useful for tracking follow on malicious activity.
5. Taylor the honey file to the host system so as to project an air of authenticity and criticality. This increases the chance it will be accessed by a hacker.  Also don’t put obvious windows server type files on a unix server or vice versa.

The time and effort invested in creating the honey files will directly impact the effectiveness of the files when in use.

Think of scenarios where developers or server admins might have “accidently” left valuable information on a server prior to it going live and then forgotten to remove it later on.

It is recommended that several types of honey file be employed to increase overall effectives.

1. Fake Database honey file. A database that contains bogus information and can be monitored strictly. Databases are high priority targets for hackers
2. Fake Procedure documents with embedded fake login information. Any access attempt by credentials listed in these documents can be considered malicious hacker activity and show a hacker has file system access on the system.
3. Fake configuration text files. Specific Unused IP addresses can be listed in these files and monitored to alert on attacks.

So what is the logic behind this ?

The goal is to seed juicy files throughout your environment and configure a high level of alerts and monitoring on these files.  These files will be the tripwire which set off the alarm bells and represents a strong indication of malicious activity.

Most systems have minimal logging enabled due to issues with load and resource utilization.  By using distributed honey files we alleviate the need to turn up logging on the majority of systems and have a more targeted and accurate indication of malicious activity with a vastly reduced number of false positives when compared to the traditional Intrusion Detections systems. 

Notes

Honeyfiles: Deceptive Files for Intrusion Detection  -

http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA484922

Differentiating mobile devices

Disclaimer: These be the thoughts and ramblings of the author, not necessarily those of his employer, management or any other fellow lackies.

When company management seeks to differentiate between devices and attempt to ban certain categories of device from the workplace they can often fail to realize that categories have merged and cannot easily be separated.

Apple mobile devices, for instance, all run the same operating system and apps So banning IPad tablets but not IPhones does nothing from a security, capability or risk standpoint. The same apps and capabilities exist on the phones as the tablets.

In fact, phone calls can be made from an iPad using google voice to any landline, so would that not make an iPad fit into the phone category?

If you say no then would you be classifying the IPad as a tablet on a mere size basis ?

Phones are getting bigger. The galaxy note 2 phone is 5.5 inches. The new iPad mini is only 7.8 inches and has a cellular radio option available. The ipod touch is only 4 inches but has no cellular radio. Which is a phone and which is a tablet ?

I would argue that the whole phone / tablet differentiation is bogus as tablets can have the same operating system , hardware and uses as a phone.

Trying to restrict tablet use only serves to alienate a subset of workers and show managements lack of a true understanding of modern mobile devices.

S. Russell Dyer BS CNE CISSP CRISC Security+ CICP
Mobile device Guru.

The wire is the key

Disclaimer: These be the authors thoughts and ramblings, no other may claim ownership of them. They are not necessarily the thoughts, policies or mindset if the authors employer, management, or fellow slaves.

The wire is the key to enterprise security. Whoever owns the wire holds the keys to the kingdom. Make sure your network security department has the tools to " own the wire".

The majority of Data leakages and breaches happen over the wire, and the wire is what we must maintain a laser focus on.

Sure, log correlation can yield valuable information in a post breach scenario, but the real time relevancy if the traffic on the wire far outweighs the patch detain of server, workstation and device logs.

Think if the fox in the henhouse. Does the farmer want his first alert of trouble to be screaming gens getting slaughtered or would he rather see the fox approaching across an open field and gave time to prevent the slaughter.

This is why a system that monitors the traffic on the wire is an enterprise imperative. Such s system can be a hard sell to executives, as it may not be a regulatory requirement, or helpful to external auditors focused on logs and reports. But the seemingly high cost of such a system pales into insignificance alongside the financial and reputation costs of even a small data breach.

So the enterprises should invest in network monitoring software which can show, alert, and capture, traffic on the wire. This allows the information security teams to identify, intercept and prevent breaches.

All information security teams prefer Prevention of breaches, but are often limited by prior management funding and system acquisition decisions to post breach analysis.

That's all for now

S. Russell Dyer BS CNE CISSP CRISC Security +

Location:Okemos Rd,Okemos,United States