Security Ripcord

Once again I find myself pointing to tweets by Richard Bejtlich. This time it was actually a retweet of Hogfly who runs the Forensic Incident Response blog. Hogfly recently pointed out an article in Aviation Week titled “China’s Role In JSF’s Spiraling Costs“. This article demonstrates the actual cost for a specific project associated with industrial espionage, nation state infiltration of critical infrastructures, and general criminal activity. A blog post by Richard Stiennon, titled “The first thing we do, is hack all the lawyers“, also showed how these same threat agents are leveraging third-party relationships to impact specific projects. I like these articles because they provide specific numbers relating to cost of impact. “…$40 billion…” “…costs at tens of billions of dollars…”

These two examples show both ends of the information technology (IT) spectrum. The defense contractors responsible for the Joint Strike Fighter (JSF) should have had decent security in place to include security testing and monitoring. The majority of law offices will not have security practices that met these standards. In most cases the IT security considerations employed by law offices will actually fall at the other end of the spectrum: operating without significant information security considerations. But, in the end the result of both cases was the same.

I believe that it is pretty safe to conclude that the threat agents responsible for these and similar breaches did not just attach to the networks and start exfiltrating data. Rather, these successful attacks very likely required the use of a combination of known and discovered exploits to gain access, persistent, and propagate within these networks. It is also logical to conclude that their activities generated system and network-based artifacts that outlined their activity, even if that activity mimicked normal and authorized operational activity. Understanding these system and network-based artifacts is an important step to preventing and detecting attempts to infiltrate a network. Another key component is detecting exploitable vulnerabilities before they can be leveraged against the resources in a network.

Early detection is why security professionals encourage network mapping, vulnerability scanning, penetration testing, research and development, and monitoring. Security teams that provide penetration testing services should have an understanding of the techniques applied by current and past threat agents. They should also have a keen eye for leveraging the resources and services to their advantage to demonstrate the ingenuity attackers will implement after the initial compromise of a network. Tom Liston of InGuardians has a plethora of stories that demonstrate how he circumvented good security implementations using common sense and experience with a wide variety of technologies. The result of such penetration testing will generate system and network-based artifacts that can be leveraged to train a organization’s security and information technology administrators to detect and identify similar activity.

Research into technologies deployed in test networks and off-line implementations provide valuable information without impacting an organization’s business assets. It also reduces the cost of effort by providing beneficial information to all businesses employing a technology rather than a single instance where the organization hordes the information to prevent distribution to threat agents. When the results of research are presented to security professionals, IT administrators, IT management, and corporate executives all of these parties benefit from the knowledge and are able to leverage the information to assess and use it to improve their security and effectiveness of their business assets.

While writing this Richard tweeted (if you are not following him then you should stop reading and take care of it right now) to additional insights that are relative to my point. “Exploits aren’t as important as some think. I worked cases where not even active intruders on a corp network inspired appropriate concern!” and “Tech people should consider that IT and sec are one of many factors that mgt weighs. I fear it’s underweighted, but it’s not tech’s call.” Both of these are very true and have played a significant role in the persistence of many breaches including those pointed out at the beginning of this post. I too have experienced active intrusions with manual (rather than automated) system interactions, supported by specific system and network-based artifacts, that were downplayed and eventually treated as a malware infestation.  Even the experiences of multiple incident response professionals was not enough to change the opinions of the administrations, IT managers, and executives of these organizations. This attitude was born out of inexperience in the types of activities associated with a network’s initial compromise, persistence of the compromise, propagation to additional resources, and exfiltration of data.  Experience that might have been achieved by monitoring the data produced by penetration testing. Of course, it also requires a mind that is not specifically limited by business restrictions and is open to new possibilities that are born out of sublime and criminal research into information technologies.

Go forth and do good things,

Don C. Weber

When I started working for IBM’s Emergency Response Team I was a little intimidated about walking into a client’s environment and quickly providing incident response leadership. Luckily I was trained by Chris Pogue and Harlan Carvey to consider three things when I got on-site:

• What are you trying to answer?
• What data do you need to answer it?
• How do you get that data?

Obviously the first question is the hardest to answer (although, perhaps, not the most challenging). I often find myself having Car Talk-style conversations where you talk about the situation for an hour or two and then somebody says something to the effect of: “Oh, yeah. And we have this service running over here.”

It always amazes me how similar many of the security issues are across companies with decent security programs and teams. The security teams work hard to identify situations before they happen but incidents still occur and the teams struggle with pulling all of the information together. Disciplined incident response comes with experience. Not just experience within the security team, but experience throughout the organization. Most companies have information technology (IT) divisions with silo-ed experience (I am not saying it is bad, just natural). The web application developers and administrators know the web applications and web logs. Database administrators know the database logs, how verbose they are, how to retrieve them, and what can be turned on and off. Network administrators know what is logging where, what has been disabled, what can be turned up. Etc, Etc. Of course there is some overlap, but this example demonstrates that a lot of internal interaction may be required to initiate an incident response.

This silo-ing can complicate things but it is often manageable. The situations that prove to be more challenging are those that involve external services and equipment. Security teams are not usually consulted when service level agreements with external entities are formulated. Any third-party organization worth their salt will be prepared to provide information and action during critical times. But experience is the only way to determine the proper channels and methods of request to initiate the actions necessary to facilitate an efficient incident response. Acquiring data, removing services, increasing logging, and physically accessing a facility are just a few of the things that could increase the gap between incident identification and response.

Another thing that comes into play during an active incident response is the review of unique data types. I have assisted in several instances where an incident involved a web application running on an Apache server. The Apache web logs did not include any POST information which may have provided artifacts relating to the incident. As these web logs were the primary method for detecting anomalies the security team quickly realized that with the default configuration they may have been missing a few things. Digging a little deeper by including web application administrators and developers additional logs were identified. In a recent case the development team used Apache log4j to produce excellent activity information for debugging. As it did not introduce a performance hit to the server the developers just left the debugging code alone. The end result was a detailed log of the web server activity. The only real hick-up was that each entry was undocumented and multi-lined making it difficult to review by common automated processes. But, in the end, very helpful.

So, again, we come back around to the same incident response-related conclusion: Preparation is KEY. Understanding how things interact and who is involved is critical to reducing the time involved during each step of an incident response. But where to start with preparation? The results of an actual incident or a penetration test provide excellent examples and supporting data. Incident response scenarios are also very helpful but can be difficult to design and get everybody involved. To be honest, I have been a big advocate of “incident response scenarios” and I have told many people to develop them. But, looking back, I realize how hard it is for an organization to do this. Heck, it was hard for me when I was specifically thinking about and devoting time to developing a good incident response scenario. Therefore I am going to change my future recommendations from  developing incident response scenarios to performing system walk-throughs.

I made this decision when I found myself leaning back in a chair, looking at a white-boarded diagram of a system (by this I mean a group of resources combined for a specific purpose), and trying to determine what we needed to understand what might have happened during an incident. It was excellent because I also found myself and the security team asking questions to which we did not have immediate answers. I also found myself thinking about how I would have accomplished a specific set of actions relating to the incident. Coming up with these possibilities lead me to asking additional questions and identifying other resources-of-concern and data that could be used to identify useful network and system artifacts.

Therefore, my recommendation is that security teams periodically perform a system walk-through for various IT implementations in their organization. See how systems walk-throughs work and let us know your experiences. Pick one thing at a time when you start and see where it takes you. Focus on the things that will provide you information about a specific activity. Brain-storm situations and talk about the system and network-based artifacts that would be helpful. Folllow up on these ideas and pull in personnel to provide additional information when necessary. This will increase their experience and begin the collaboration process that may prove vitally important in future incidents. I also believe that these interactions will help identify risks, weaknesses, and vulnerabilities that can be easily addressed and increase the overall security of the organization.

Go forth and do good things,

Don C. Weber

Mentoring can be a powerful learning tool for learning specific topics. I have been thinking about mentoring a little bit because I have often found myself thinking that a mentor would be beneficial to my technological and managerial growth.  From my experiences I have determined there are a few requirements to setting up a good mentoring situation. Now, I am not a professional mentor, so, your mileage may vary.

• Focus: a broad range of mentoring subjects do not really work. A mentoring experience should be focused on a specific area.
• Time: both mentor and mentee must have time and inclination for the mentoring experience. Mentoring requires consistent meetings and reviews.
• Experience: A mentor must have knowledge of the subject and mentoring. A mentee must be able to learn the subject and be willing to branch out without encouragement.
• Desire: Both parties need to have a strong desire to participate from the beginning to the end of the mentoring experience.
• End State: both mentor and mentee must have an understanding of when the mentoring experience will end.  This may be after a specific set of goals is reached or a after a specific time period.

Personally, I don’t think that a blossoming Information Technology (IT) Security professional needs mentoring outside of the educational practices implemented by their place of employment. But that is the key: place of employment. Without a job it is difficult to implement the requirements that I listed above. Obviously this means that my list should include the additional requirement of: a job. Of course, a job is generally why a blossoming IT Security professional wants to enter into a mentoring experience.

How do people attempting to enter the IT Security profession get past this gap? My thoughts: effort, tenacity, and the will to teach. A well rounded IT Security professional starts by knowing a lot of things. They slowly, via experience, move to knowing a lot about a lot of things and eventually realize that they do not know and have not done everything. Once they realize they do not know everything they accept the fact that they will be learning during their whole career. I also believe that continuous effort and vocalism are requirements for becoming a well-rounded IT Security professional. Not only does this get you noticed by your peers, it expresses confidence to other administrators and managers.

As IT Security professionals mature they tend to filter into specific areas of focus. This usually means that the influential people in their lives become more narrow and they start to enter into good peer-mentoring relationships. By “peer-mentoring” I mean that each person grows from the other’s experiences. They drive each other to dig deeper and accomplish more. Eventually, people start developing other interests and the “peer-mentoring” relationships shift. But the excellent thing is that, generally, the previous relationships (business or friend) remain strong and continue throughout the years. At some point, interests will diverge again and collaboration will continue.

So, if you are just getting into IT Security or attempting to transition to a new focus area, do not get stifled or discouraged by the lack of mentoring opportunities. Rather, put yourself out there. Start working on personal projects. Tell people about your experiences, failures and success (because BOTH are important to the learning process). Do not be discouraged by critical feed back and have fun even if the subject is hard from start to finish. Remember, experience comes with time and effort. Learning the hard way helps people understand the easy and efficient way. In the end, people will notice and you will have achieved your goal.

Go forth and do good things,

Don C. Weber

Drop The Refrain

The refrain “make it too expensive for the attackers” needs to be retired from the security professional’s vocabulary.  It is not going to happen.  Making it “too expensive” is not S.M.A.R.T. It also means absolutely nothing to the attackers.  The guidance security professionals need to be pushing is that managed business processes and security controls will reduce the overall cost associated with responding to each attack as they are experienced.  It is not a matter of who will do the attacking, when they will do it, or how many resources they have behind them.  It is the understanding that attacks are going to occur, most attacks will involve techniques to which an organization can identify and respond, and some attacks will occur using new methodologies and technologies to which the organization can identify and respond.

Attacker’s Viewpoint

Let’s take a look at the malicious hacker list Roger Grimes put together (which I like very much, BTW) and see how each group is affected by the overall “expense” of their efforts..

Cyber criminals: as these people are after big financial gain they understand that there will be cost involved with their efforts.  The bigger the pay-out the more time and effort they are willing to spend.  However, they just don’t turn away from targets.  Hard targets are softened by time.  Over time there will be new vulnerabilities, new attack methodologies, new personnel, etc.  If something is currently difficult they may roll over to other prey, but they will come back around.

Spammers and adware spreaders: these attackers are generally not concerned with specific targets.  However, the way spammers and adware spreaders conduct their business is interesting to other malicious hackers.  The research and development of this group can easily be leveraged for other purposes.  They try everything in the book and then write new pages when those do not work any more.  They are not concerned about how much it costs to get around your controls because they are best at presenting a moving target.  Basically making it more expensive for customers to keep up with them.

Advanced persistent threat (APT) agents: these guys are good at getting in.  They are also good at being patient.  Biding their time for specific opportunities.  They try a few things to get in and, if that doesn’t work, they try something else.  As they have multiple targets (or so it appears) they move onto the next target on their list.  Then, after a time, they roll back to a targeted organization where their tactics have been unsuccessful and they try something else.  Security programs and controls are not making it more expensive for them.  They know it is a part of the game and they just continue until they are successful.

Corporate spies: well, this attacker is most likely (yes, I’m guessing) expensive to begin with.  I have not run into any of these people or cases, nor have I heard much about them.   But, I understand the mentality.  They could be heavily trained or simply people exploiting an opportunity.  These people are usually in a position where they can manipulate the security controls, or feel they can get away with their efforts despite the controls.  In other words, the reward already out-weighs the risk.

Hacktivists: this group is probably the most affected by the cost of their efforts.  However, they will most likely be associated with the Rogue hacker category and thereby reap the rewards of their efforts.  Which, in turn, means that cost does not affect them much as they rely on targets of opportunity that will produce the actions they desire.

Cyber warriors: although military commanders do take into consideration cost of resources, their limits are beyond those of most corporations.  Additionally, once the cost reaches a certain point then the tactics for this group changes to kinetic solutions.

Rogue hackers: one word for these guys: “challenge.”  If it is a challenge is it really too expensive?  To this group time and effort is nothing.  Once they set their sights they either work it till they are bored with it or they accomplish their objectives.  If a group of these individuals gets their collective heads together, then cost matters even less.  Certainly a good security effort will prevent many unmotivated rogue hackers, but those that are motivated have a purpose where cost is of little consequence.

In Need of a New Catchphrase

Therefore I say out with the old refrain and in with something new.  Preferably something that is a little more Specific, Measurable, Attainable, Relevant, and Time-bound.  I prefer more direct and implementable guidance that helps build cross-functional incident response efforts and teams.  However, for those who require those “elevator statements” (don’t we all at some point) maybe try one of my favorites: “reducing the gap between compromise and identification.”  Because the old “make it too expensive for the attackers” statement is placing the wrong emphasis on the overall effort and makes people, particularly executives, think that 100% secure is an obtainable goal.  When we all know that information security is a sustained effort that will continue as long as the organization exists.

Go forth and do good things,

Don C. Weber

Following up on any project is key.  Talking to all involved about what has happened, why it happened, how it could have better, what worked very well, etc is the key to improvement.  So, why aren’t organizations that experience a security related incident able to prevent or curtail future incidents?  Basically because they are not following up the incident with a lessons learned, or they are not doing it properly.

Incident Response should be handled like any other project.  It should be managed.  As most incident responders are aware, SANS GCIH course outlines 6 distinct phases of an incident response:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery, and
6. Lessons Learned

Ah, Lessons Learned is the final step.  Actually, it is circular, so the final step leads into the first step.   I say leads into whereas a better metaphor might be “feeds.”  Or in the terms of following flow charts, for you management types out there, the outputs of Lessons Learned are the inputs of Preparation.  Here’s a question for you though, during your preparation phase did you look at the methodologies that you use to improve how you identify, prioritize, address, and follow-up on your lessons learned?  Or, when you are finished with your lessons learned meeting, do you have a list of action items that have been assigned to a specific individual who understands the criteria for successfully completing the action?

I just asked two questions that took your simple lessons learned meeting from a quick five minute session to a thirty minute plus session.  Although you might think that the issues will drive how long this meeting will last, in actuality that is not correct.  With proper methodology, in other words a practiced plan, this meeting can still be very quick while producing the key outputs that are necessary to augment your preparation phase.

Silver Bullet time.  Yes, I know, you want the silver bullet that is going to help you increase the effectiveness of your lessons learned process.  Guess what!!  Most likely you already have it.  Do you use process management to plan your software, hardware, or infrastructure development?  Bingo, then you have the means to improve your lessons learned.  Start using the processes that you already have in place.  I say this because it is the fastest and cheapest method to gaining control over this process.

For those of you who do not have a process in place, never fear, I have one word for you: Why.  Just ask why.  But ask it five times.  Asking why five times is the technique for determining root cause.  Gasp, Root Cause Analysis.  It is used during the Six Sigma process as well as being integrated into other project development schemes.  In his 5 Whys post Eric Ries explains that Taiichi Ohno of Toyota fame wrote about this technique in his book Toyota Production System: Beyond Large-Scale Production.

Now, this might seem silly to some at first.  It will seem especially silly to those individuals and groups that are not use to management their projects or doing root cause analysis.  This is where the longer meetings are going to come into play.  Of course, this is true of any new process.  New things take time to understand and get use to performing.  For some people the learning curve on how to conduct themselves in these meetings is going to be a long and tough journey.  But by consistently applying one of these methodologies to your lessons learned process you will find that each of your meetings is shorter and more productive.  The implementors will be happier because they are being heard (if they are participating) and the managers and executives will be happier because of the increased productivity and effectiveness of the end results.

Certainly I have only touched on this topic briefly.  If you have techniques that have worked to improve the effectiveness of your lessons learned meetings, please share them with us in the comments.

Go forth and do good things,

Don C. Weber

http://www.sans.org/?utm_source=web&utm_medium=text-ad&utm_content=affiliate_link1&utm_campaign=Cutaway_Security

I was completely wrong about the outcome of the UFC® 94 ST-PIERRE VS PENN 2 fight.  I was hoping that BJ would pull it out but it was very apparent by half-way through the second round that GSP had the better strategy.

From an IT security stand point what can we learn from this?  Well, the first thing that comes to mind is the fact that this was the second fight between these two fighters.  The first fight was won by GSP in a split decision at the end of three rounds.  What this means to my point is that these fighters had experience with each other.  They had stood up and traded punches and also grappled on the ground.  This usually means that second fights are exciting because fighters change their tactics to overcome their opponents weaknesses while also strengthening their own.  In the work-up to the second fight GSP did just that.  BJ, however, did not.  He came out and fought the same fight, worked hard, did his best, and got beaten.

Can you see where I am going with this?  IT environments generally do not grow and change.  Their business and security controls fight the same good fight everyday but, generally, they remain stagnant or slowly build up extra layers to cover up, instead of fixing, weaknesses.  But the core usually remains the same and when push comes to shove the old weaknesses are exposed.

I would like to say that I have some cool way that would allow an environment to modify itself on a regular basis.  Some way to change or rotate paths, protocols, and technologies.  I do not.  It is not very cost effective to operate in this manner.  It takes time, money, knowledge, and man-hours to do it effectively.  Accuracy is also a factor as changes can lead to mistakes in configuration and implementation.  These factors impose a heavy burden on the profit margin which in turn means that the risks associated with more stagnant defense are acceptable.

Fortunately for us IT business and security is not just a one-on-one battle.  It might be at first, but as in real war (which IT resembles more than the UFC) once you get in a fight, if you can hold off your opponent for a sufficient amount of time, help will arrive.  This help can come in the form of either outside expertise or law enforcement.  The important part is to be in a position that you can identify when you are being attacked and hold off the opponent long enough to gain enough information about them, or the weaknesses they are trying to exploit, to make the appropriate adjustments and, if necessary, call in help.

GSP studied his opponent much like a malicious hacker will a target.  He analyzed his opponent  for exploitable weaknesses, trained on how to overcome those weaknesses, and then attacked them with overwhelming force.  Sound similar to Conficker/Downadup? BJ trained for the fight and I am sure did everything he and his staff could do to identify and train towards GSP’s weaknesses.  But what he was not prepared for was to quickly modify his strategy to protect his own weaknesses and give himself the ability to regain the initiative.  Thus, GSP was victorious.

So take a look around your business.  Is there anything that you could modify on a regular basis to maintain a more challenging target to your opponents?  Have you effectively trained your staff to calmly and effectively cope with the highly stressful events that surround an adverse event or malicious incident?  Have you looked at yourself from the outside to determine the weakness that are the most logical to attack?  Do you have a plan to protect internal assets when your defenses are breached?  Do you know who the calvary is and how to contact them in the case of an emergency?  Do they know who you are?

Take a lesson from BJ and GSP.  Realize that a stagnant target is more easily attacked and beaten by an intelligent and well-prepared opponent.  Remember, knowing you have a problem is the first step to a cure.  Also, listen to what other people say about your environment and approach to solutions, because you don’t know what you are doing wrong until somebody tells you.

By the way, great job BJ Penn and Georges St-Pierre.  Although GSP won you are both winners for training hard and giving it your all.  Keep up the good work.

Go forth and do good things,

Don C. Weber

Although we have seen some recent activity concerning a hacked road-side construction sign, you should be aware that this situation was documented on Jun 23, 2006 at 11:49 a.m. on the Rotten Eggs website in an article titled (amazingly enough): Hacking electronic road signs.  Of course the newest article is a little more in-depth, but this type of activity and vulnerability should not have been a surprise to anyone.  Those of you who subscribe here are very familiar with this type of situation.

Now that the situation is back in the public eye, how do we leverage it with our friends, family, co-workers, customers, and management?

What this situation does is emphasize the fact that default passwords and devices with built in reset capabilities should be controlled in a much better manner.  The changing of a road sign will not last very long or adversely affect (generally) anything beyond inconvenience.  The real problem is the mentality of companies creating devices that operate in this manner.  Things are still getting built this way and we have to make the logical leap that developers of hardware, programs, operating systems, network devices, mobile devices, and applications are making the same mistakes even today.

We can use this opportunity to remind our our friends, family, co-workers, customers, and managers to evaluate their deployed technologies for default passwords.  We should also remind them that they need to take these things into consideration during the initial purchasing process where they are evaluating new technologies. That is the only way to find these types of problems and mitigate the risk properly before purchasing and deployment.  Should they find devices or applications with these limited or hamstrung security capabilities they should do a risk assessment to determine the best method to increase the security surrounding the technology or what can effectively and securely replace it.

Your mission is to determine a way to put the preceding paragraph into words and terms that your audience will understand.  Most of you reading this know exactly what I talked about.  You cannot assume that your audience will be able to understand it in the same manner.  If they don’t understand it they cannot proceed effectively.  Think about your audience before approaching them with your recommendations.  Determine the proper terminology, references, and examples to help them make an informed assessment and conclusion.  Be prepared with solutions for situations that you know exist and methods to move forward and locating those situations that have not identified.  And be sure to stress the importance of taking security into consideration during the initial evaluation and purchasing process.

Go forth and do good things,

Don C. Weber

Can you identify the root cause?  What I mean is, if you were presented with a question, about how an event occurred, could you show the logical progression of how that event occurred?  And then describe to me the actions that followed?  Maybe you are not the network/system/security administrator of your organization.  Fine.  Can your people answer those questions for you?

The SANS Glossary of Security Terms defines an event as “an observable occurrence in a system or network.”  It also defines an incident as “an adverse network event in an information system or network or the threat of the occurrence of such an event.”  But I am not talking about an incident.  I don’t care if you have had an incident.  What I want to know is if your organization has the ability to determine the steps that lead up to and happened after an “event.”

Because if you cannot describe to me the circumstances surrounding an event, you cannot describe to me the circumstances surrounding an incident.  If you cannot tell me who initiated a connection to your web server from an internal asset, then you cannot tell me the actions that person performed after creating that connection.

Do you want to know what happened to your information or system at a certain time period?  Are you obligated to know by policy, regulation, or just plain common sense?   I can go so many different directions with this thought process.  Really, it all depends on the persons that I am talking to and their roles within the organization.

One of the first things that I tell people who are just starting out in the security industry is that security is really the art of implementing good business practices.  Although there are several specialized portions of the security industry, the majority of us are employed to ensure an organization is implementing sound and well documented methods to maintain a well-structured and profitable business.  Unfortunately, the thing about good business practices is that it is driven by continued profit.  And as we can see from the state of the economy, those profits are the very thing that can blind us to the affects of risk.  Or at least provide us with the motivation to accept the risk.  Of course I would love to believe my predictions from my last post about Conficker/Downadup – Securing The Internet as it is in my nature to trust these types of eventualities.  But most likely a writer over at VistaSpyware.com is correct in the assumption that it is not in the nature of the industry to do so.

Although you might think that I am straying from the “Root Cause” theme here I am not.  Because being able to determine root cause and follow on actions invariably depends on the methodology that you and your organization have implemented within your environment.  If you have been lazy or sloppy about patch and asset management then you are not going to be able to attest to the state of your infrastructure.  If you have decided to roll back logging and alerting because of the impact to storage space or network bandwidth instead of augmenting the technologies to handle the loads properly then you are not going to be able to attest to the state of your infrastructure.  Scaling back on the infrastructure that does not necessarily provide an immediately measurable positive monetary impact on your environment will eventually lead to a state that you cannot provide accurate and detailed information about the root cause and follow on actions of an event.

Certainly, a good incident response team can piece many things together.  Through hard work, knowledge, perseverance, and a lot (and I mean A LOT) of your money they will be able to provide you with the best report they can generate.  And sometimes the information will be helpful possibly finding the root cause and follow on actions.  But there are going to be other times when they cannot.  Sometimes they will finish the initial contact phone call by providing you with quick recommendations on how to proceed, thanking you for your time, and then gently let you know that there just is not enough information to proceed with an analysis.

Now, here is the part where I ask you if you want this to be you.  Well, actually, I am not going to.  You have already decided.  Or, it has already been decided for you.  What I mean by that is that the resources you have already been given are in place and you will more than likely not get anything else.  Or, at least, you need to begin thinking that way.  I say that because everybody needs to start thinking about the resources that they already have in place and start implementing them properly.  Start utilizing the technologies that have been deployed, determine how they work together and can augment each other, and then configure and manage them correctly.  Pull back and start asking yourself, your team members, and your organization if you are doing the basics correctly.  After you have done that, take a look at your more advanced technologies and determine if they are employed correctly to assist your organization in implementing the basics more effectively and efficiently.  Because that is how the more advanced technologies are intended to be implemented.  Until you have done all of this you should not be trying to find the next best security or business technology to act as your silver bullet or to help you “pull it all together.”  Because if you do not have it all together in the first place, dropping something more complex into the mix is going to move you further away from your ultimate goal of cost effective implementation, stream-lined business methodology, and low-risk high-yield technology to revenue ratios (not sure where that last one came from, but it sounds good so I’ll leave it in).

To summarize, if you want to know when, how, and why you or your organization got hacked you have to prepare before hand.  You have to employ basic business, technology, and security strategies thoroughly and correctly.  Only then will you get a good answer to the question, “What was the root cause of this event/incident and what has occurred since the initial occurrence?”

Go forth and do good things,

Don C. Weber

I have to say one thing for the rash of Conficker/Downadup infected systems that are plaguing businesses around the world:  This malware is helping the overall security of the Internet.

Once we are past this round of malware it will definitely be harder to propagate a mass infection.  Scoff if you will, but I am serious.  I admit that this worm is building a very large network of infected systems.  But for those businesses that are addressing this malware attack they are discovering the weaknesses within their infrastructures and response techniques.  The down-times associated with locked accounts, offline servers, disrupted services due to network traffic saturation, poorly implemented / broken patch management capabilities, broken backup procedures (BTW, are your backups infected?), etc are helping the information technology staff justify their recommendations to fix these issues.  Whether the recommendations were already in place or are now forth coming is really irrelevant.  The fact is that once businesses start adding up the costs associated with the response to this malware, executives should start taking notice of the potential return on investment (gasp, Securit ROI – opps, please don’t start THAT conversation AGAIN) of their network security and management technologies.

I am certainly not saying that after this malware tumbles off into the distance that there will not be another instance of a mass infection.  What I am saying is that because of the Conficker/Downadup malware, many organizations are going to be better prepared to avoid, limit, eradicate, and return to business as usual.  This will, in-turn, reduce the number of infected systems and the speed that new malware propagates across the Internet.  I wish I could also say that this will help other non-business computers such as those owned by schools, non-profit organizations, home-users, and [add your own choice here], but that is, unfortunately, just not the case.

One thing I can recommend is that IT staff and management take advantage of this situation and make their recommendations quickly with an emphasis on prioritization.  Recent disasters have shown how short lived memories associated with purchasing and implementing protections associated with business continuity and disaster recovery can be.  Determining which technologies will give you the most bang for your buck while also increasing your infrastructure’s preparedness with an emphasis on reducing the gap between an incident and the organization’s initial response is key.  Organize the rest of your list with these issues in mind.  Hopefully, you will get the number one priority on your list.  But if your list is not prioritized you may be stuck with a box of stuff that will leave you scratching your head and wondering how it is going to help future incident responses and general business requirements.

Go forth and do good things,

Don C. Weber

** It was recommended that I add a disclaimer stating I am not a lawyer.  So, be advised, I am not a lawyer **

*** Update 2: shrdlu points out (see comments below) that I missed the very last line of the PSB opinion on security consulting.  Thank you, shrdlu.  So, until they change that opinion all is well. ***

The SANS Computer Forensics Blog post Digital Forensics Professionals: Texas PI Legislation Interpreted got me thinking about the Texas PI laws again so I decided to take another look at the TEXAS OCCUPATIONS CODE CHAPTER 1702.  What I have found concerns me very much and if you or your company does forensic or security consulting work in the State of Texas then you had better read it as well and pass it onto your lawyers BEFORE you do anymore work in this state.

Basically, the State of Texas is now regulating all of the information security consultant industry within its boundaries.  This *DOES NOT* include the security departments of individual businesses.

Let’s start with a bit of clarification.  The State of Texas designates anybody doing investigative or security consultant work as a “company.”  If you do not understand this then reviewing the statue is going to confuse you at first.  With this in mind, here is the definition of “investigations” as put forth in Chapter 1702.

Sec. 1702.104.  INVESTIGATIONS COMPANY.

(a)  A person acts as an investigations company for the purposes of this chapter if the person:

(1)  engages in the business of obtaining or furnishing, or accepts employment to obtain or furnish, information related to:

(A)  crime or wrongs done or threatened against a state or the United States;

(B)  the identity, habits, business, occupation, knowledge, efficiency, loyalty, movement, location, affiliations, associations, transactions, acts, reputation, or character of a person;

(C)  the location, disposition, or recovery of lost or stolen property; or

(D)  the cause or responsibility for a fire, libel, loss, accident, damage, or injury to a person or to property;

(2)  engages in the business of securing, or accepts employment to secure, evidence for use before a court, board, officer, or investigating committee;

(3)  engages in the business of securing, or accepts employment to secure, the electronic tracking of the location of an individual or motor vehicle other than for criminal justice purposes by or on behalf of a governmental entity; or

(4)  engages in the business of protecting, or accepts employment to protect, an individual from bodily harm through the use of a personal protection officer.

(b)  For purposes of Subsection (a)(1), obtaining or furnishing information includes information obtained or furnished through the review and analysis of, and the investigation into the content of, computer-based data not available to the public.

After contacting the Private Security Bureau, which is a division of the Texas Department of Public Safety, I was told that the State of Texas regulates “investigations” so that the persons conducting them are qualified.  To ensure that investigators are qualified they are required to comply with Sec. 1702.113.  GENERAL QUALIFICATIONS FOR LICENSE, CERTIFICATE OF REGISTRATION, OR SECURITY OFFICER COMMISSION (which are basic employment requirements) and:

Sec. 1702.114.  ADDITIONAL QUALIFICATIONS FOR INVESTIGATIONS COMPANY
LICENSE.

(a)  An applicant for a license to engage in the business of an
investigations company or the applicant’s manager must have, before the
date of the application, three consecutive years’ experience in the
investigative field as an employee, manager, or owner of an investigations
company or satisfy other requirements set by the commission.

Now I do understand the need to provide a governing hand to protect the public from “investigators.”  If the state feels it is necessary then so be it.  This is basically stating that you have to have three years experience before you can operate individually or be the primary investigator of a company (yours or somebody elses).  More explaintion about this can be found in the PSB Opinion Summaries in the section titled Computer Forensics.

The part of Chapter 1702 that is really going to concern people is the guidance it provides for people the state considers as “security services contractors” or “private security consulting company.”  Here is the guide lines for what constitutes as a “private security consulting company.”

Sec. 1702.1045.  PRIVATE SECURITY CONSULTING COMPANY.

A person acts as a private security consulting company for purposes of this chapter if the person:

(1)  consults, advises, trains, or specifies or recommends products, services, methods, or procedures in the security or loss prevention industry;

(2)  provides a service described by Subdivision (1) on an independent basis and without being affiliated with a particular service or product;  and

(3)  meets the experience requirements established by the board.

Guidance on how this applies can also be found in the PSB Opinion Summaries in the section titled Computer Network Vulnerability Testing Firms.  Here is the part that stands out to me:

However, while the Bureau regulates consultants in the “security industry
or loss prevention industry,” these latter phrase is not explicitly defined
in the statute. It is therefore necessary to look to the rest of the
statute in order to understand to which services the private security
consultant’s licensure requirement applies.

It is reasonable to consider those industries otherwise regulated by the
Private Security Act as reflecting the scope of the phrase “security
industry or loss prevention industry.” In other words, the definitions are
implied by those services that are regulated by the statute, viz., security
guards, locksmiths, alarm system installers and monitors, and private
investigators, and not software designers, installers or suppliers.

Thus, the industries that are directly regulated are the same industries
about which one cannot consult without a license. Because the Private
Security Bureau does not regulate software designers, installers, or
suppliers, it also does not regulate those who provide consulting services
related to computer network security.

What this tells me is basically, if you are a security consultant in the State of Texas you must be registered.  This requires that you apply for a license and pass the Qualified Manager’s Exam.  This is the same exam that is required to become a licensed Private Investigator only where as Private Investigators only pay $350 to take the exam, security consultants have to pay $400 to take the exam, as outlined in Chapter 1702.  This exam simply shows that the person passing the exam has an understanding of the regulations we are covering and nothing specific to investigations or consulting.  The additional requirements to become a licensed security services contractor include:

Sec. 1702.115.  ADDITIONAL QUALIFICATIONS FOR SECURITY SERVICES CONTRACTOR LICENSE.

(a)  An applicant for a license to engage in the business of a security services contractor or the applicant’s manager must have, before the date of the application, two consecutive years’ experience in each security services field for which the person applies as an employee, manager, or owner of a security services contractor or satisfy other requirements set by the commission.

(b)  The applicant’s experience must have been obtained legally and must be:

(1)  reviewed by the commission or the director; and

(2)  determined to be adequate to qualify the applicant to engage in the business of a security services contractor.

As a security profession in the State of Texas I am concerned that I cannot consult, advise, train, or specify or recommend products, services, methods, or procedures in the security or loss prevention industry without being a licensed security services contractor.  This basically tells me that I cannot talk to anybody (family, friends, public gatherings like the PTA or a church, in addition to business relationships) about these issues until I am licensed.  Consultant businesses doing business within Texas should have the very same concerns.

Security professionals coming to Texas should also be concerned.  If you come to Texas to work or even to teach a class (SANS training) or give a presentation (TRISC) that consults, advises, trains, or specifies or recommends products, services, methods, or procedures in the security or loss prevention industry and you are not licensed you could be held accountable.  Specifically:

Sec. 1702.386.  UNAUTHORIZED EMPLOYMENT; OFFENSE.

(a)  A person commits an offense if the person contracts with or employs a person who is required to hold a license, registration, certificate, or commission under this chapter knowing that the person does not hold the required license, registration, certificate, or commission or who otherwise, at the time of contract or employment, is in violation of this chapter.

(b)  An offense under Subsection (a) is a Class A misdemeanor.

Although a Class A misdemeanor does not seem like much, individuals who have been found in violation of this statue may not be able to obtain a license in the future as outlined in Sec. 1702.113.  GENERAL QUALIFICATIONS FOR LICENSE, CERTIFICATE OF REGISTRATION, OR SECURITY OFFICER COMMISSION.

If you have additional information, updates, or clarification on this please leave a comment or shoot me an email so that I can update this post.

I’m starting to wonder if this blog is a violation of this statue.

Go forth and do good things,

Don C. Weber