During the second week of December I realized that our group had not used their 2012 training budget. Realizing that there was not enough time to get a formal security class under way before the end of the year, I suggested to my manager that our group use the funds to order security-related books. He gave us the green light and behold the list below. Goal is to finish them by December 31, 2013. We’ll see what happens.
All of the components associated with managing the Whole Disk Encryption (WDE) infrastructure should be classified as a High Value Asset (HVA). The backend assets contain the components involved for protecting the encryption and decryption keys that are used to encrypt hard drives. Treating the backend components of the Disk encryption environment as HVA, will ensure that the cryptographic keys are protected through a layered approach to securing the environment. This of course assumes you are architecting your security environment around various layers and are classifying certain assets as HVA’s and others at lower classifications.
Given the horrible tragedy that took place yesterday in our nation, I have been given a lot of thought to how to mitigate these shooting incidents. Given the fact that my career has been centered around protecting company resources and putting plans, processes, and procedures in place to respond to security incidents, I thought I would provide a similiar approach for dealing with school shootings.
It’s important to note when I’m referencing “assets” I”m referring to the victims involved in the given incident. Please do not take this as an insensitive term to those victims, it’s just easier as a point of reference. I would also point out that I have two boys (12 & 8) that have just as easily been victimized as those from yesterday’s incident. When I use the term “threat vector” I’m speaking mainly of the perpetrators involved in the shootings.
Being a Information Security geek for sometime I have had a significant exposure to DLP over the years and being exposed to two major vendor distributions along with processes and procedures I have found some high-level principles that should be followed.
1. Know Thy Risk – This often seems to be taken for granted, but depending upon your business model not everyones risk for data leakage will be the same. Healthcare will be more at risk for HIPAA than the Banking industry and Food Chains will be more at risk for PCI than body shops. In addition to known regulatory laws such as HIPAA and PCI you also need to assess the risk to your organization if one classification of data was leaked versus another. Once this risk assessment has been completed it will make it easier to drive priorities around your DLP initiative.
2. Data Classification – It is also important to define a Data Classification policy so that you can use this to define and drive your DLP policies. For example, you may have a Data Classification such as Highly Sensitive, Sensitive, Internal, and Public. Policy might dictate that all data identied as ‘Highly Sensitive’ must be encrypted, while data that falls under ‘Sensitive’ just needs to have strong access controls.
3. Document & Define Workflows – This is probably the most difficult aspects of DLP due primarily to dependecy upon other groups (Legal & HR) and the potential resource hours needed to manage the process. It basically comes down answering questions such as:
Who needs to be notified when an incident is created by the DLP solution? Do we need to define thresholds for the notifcations?
Who will determine if the incident is a false-positive or a real incident?
Should the data be acted upon automatically? Should we quarantine or block the data that was identified in the incident?
I’m planning on making a series of additional blog entries around various other aspects of DLP in the near future.
Have not blogged on any security-related topics in a while so I thought it was time. Scapy is a Python-driven program for generating TCP/IP packets on the fly and programtically. If you fire up Scapy on a fresh Backtrack 5 system you will be welcomed with two dependency errors; one complaining about the GNUPlot Python library and the other for PyX. I think there was another one for a GUI library, but can’t seem to find it in my Bash history.
Like most things Ubuntu/Debian the fix is pretty trivial:
apt-get install python-scitools python-pyx
There you go, happy packet hacking!
Pluggable authentication modules (PAM) are a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independent of the underlying authentication scheme. PAM was first proposed by Sun Microsystems in an Open Software Foundation Request for Comments (RFC) 86.0 dated October 1995. It was adopted as the authentication framework of the Common Desktop Environment. As a stand-alone infrastructure, PAM first appeared from an open-source, Linux-PAM, development in Red Hat Linux 3.0.4 in August 1996. PAM is currently supported in the AIX operating system, DragonFly BSD, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD and Solaris.
Below is a list of good resources related to PAM that you can use to improve your Linux security model.
Linux PAM Admin Guide
NetBSD PAM Guide
Nice PAM Tutorial
Redhat Reference for PAM Modules
Firewall Builder is a GUI application that allows you to create sophisticated firewall rules. Currently only version 4 is available in the Ubuntu repositories, so here is how to install version 5 in Ubuntu:
1. From a Terminal window type: wget http://www.fwbuilder.org/PACKAGE-GPG-KEY-fwbuilder.asc -0- | sudo apt-key add -
2. Add the line deb http://packages.fwbuilder.org/deb/stable/ VersionName contrib
Where VersionName is the string of your Ubuntu version such as natty.
3. From a Terminal window type: sudo apt-get update
4. From a Terminal window type: sudo apt-get install fwbuilder
I was actually browsing through the Freedombox site to look at the project and when I clicked on one of the links to the Linux Foundation I received the breach notification that now reads (Condensed Version):
“Linux Foundation infrastructure including LinuxFoundation.org, Linux.com, and their subdomains are down for maintenance due to a security breach that was discovered on September 8, 2011. The Linux Foundation made this decision in the interest of extreme caution and security best practices. We believe this breach was connected to the intrusion on kernel.org.”
They make the statement of “..security best practices”. If they were using security best practices should they have been breached to begin with? My hope is if and when they discover what happened is that in the interest of Open Source is that they would offer full-disclosure on the details of the incident so the Linux community can learn from the mistakes that appears to have affected kernel.org and now the Linux Foundation.
What I find interesting is that as a result of the kernel.org breach, Linux Torvalds has moved the Linux Kernel project to GitHub. So I’m wondering what assurance Linus feels that GitHub will give him that kernel.org could not? It really comes to is that they have not been breached yet.
Here is Justin’s top 5 UNIX security books.
The Fedora Infrastructure was recently compromised. Hopefully they secured the systems using the CIS Redhat Linux hardening guide.