I have been doing Information Security for a decade and a half and there is a disturbing pattern that still to this day has not abated. That pattern involves more of a philosophy than the actual scaling you would need to for designing a security solution for an organization. The scaling law I’m talking about is one that is usually recognized too late in the implementation process, namely the post-production phase of a project.
What I’m referring to is the amount of output you have to deal with that is a result of implementing a security solution without considering the resources necessary to manage and the resulting business process that need to accommodate this reality.
One of the best use cases that demonstrates this phenomena is around the implementation of a Data Loss Prevention (DLP) solution for an enterprise. A typical DLP solution usually involves three main areas:
Data in Motion – Data that traverses the network
Data at Rest – Data that is stored on disk
Endpoint Data – Data that typically is read and written to removable media
You have a number of approaches you could take. The most reasonable would be to focus on one of the three areas that consider was vital and to scale the scope of the inspections to very specific set of criteria. Is this how most DLP deployments go? No, instead usually all three are turned on at the same time and there is no scaling back of the criteria.
The result; more incidents and false-positives than fleas at the Westminster Canine convention. Once this scenario is encountered you end up scaling back your efforts and loss at least 3 months of progress. So do yourself a favor when implementing a security solution and understand what our outputs are before they are produced.
So I was looking to cleanup my Twitter favorites list and starting with the oldest one that was dated from 2011, it was from an article for using a Python script for searching the local ExploitDB instance on Backtrack.So of course it peaked my interest and click on the source link directed me to a parked domain. Common problem with Open Source tools. After performing some Google-Fu, I found a copy and downloaded it to my Kali instance and of course it didn’t work as the path for the ExploitDB path has changed.
So after a trivial change of pointing it to the correct path, bingo, it works.I have created a ‘Kali‘ repo on my Github if you want to grab it and I’m probably going to be making some updates to it over time.
Nice talk around the history of Backtrack and how it morphed into Kali Linux.
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.
There are a minimum set of events that should be logged on UNIX-like operating systems. Typically you would need to define requirements for your specific needs and add and modify them per requirements that you define.
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