Govt View on Cyber Warfare/Terrorism

This is is in response to your email to me on 5/2

Interesting how our government is currently viewing this and the legal perspectives….  Most of it isn’t news to me, but I feel like it sort of puts a wrapper around what I already knew and tied up some loose ends.  Looking fwd to getting in a solid read vs. quick scan later.

http://www.fas.org:8080/sgp/crs/natsec/R43955.pdf

I think that much of this FAS document is a "knee jerk reaction" to the Sony hacking incident in 2014. I wrote a paper in this subject a few months ago, and it is included below. Please read and make your own opinions on the matter.

Spear Phishing and User Awareness Programs

Cyber news seems to be bustling lately with Spear Phishing attempts and successful attacks. Spear Phishing tactics are becoming more and more sophisticated via well crafted and well worded emails. No longer is the wording obviously from someone that doesn't speak English. Some even go so far as to map out a plot. That is to say that the person leading the attack is carefully crafting, even predicting really, the behavior of their victim and creating a roadmap to accompany the email through a series of what would appear to be valid actions. In some of the attacks I was reading recently the authors really did their homework through other social engineering avenues in order to craft these emails and plots.

Most IT related people would probably identify one of these emails fairly quickly, but even that isn't necessarily true. How many of you reading this really "examine" your emails? Suppose you were to receive an email from someone you know within the company. Maybe it's even the guy three cubicles over. Can you honestly say that with each email you check the senders address, or review header info, or any other method of cross-checking for validity? Perhaps you are lucky enough to have a policy which enforces non-repudiation via signed emails. If so good for you.

We all know that it is the employee, the human, who is the weakest control in any environment, but they are trained. Why are these attacks still so successful today?

Let's face it. User awareness programs are successful and are useful. I would not be doing my field any favors by calling them irrelevant, and I certainly don't believe that they are irrelevant. But let's also be honest about the repetitive nature of these programs. Usually it is an annual requirement with very little accountability attached to it. Typically these trainings are presented in the nature of a slide show, computer based training, or some other easily manipulated method to just get it over with or click through to satisfy the requirement. The programs become, well, mundane and in my opinion unimportant to the person that has to take them. Over time we reach a point as humans that we become comfortable. Maybe this is because an employee has been in a job for thirty plus years. Maybe it is because an employee develops relationships and would never be duped, always recognizing the sender. Let's not forget that this person is also banking that the odds are in their favor that they will not have to encounter any forms of social engineering or attacks. Whatever the reason these email attacks are still successful quite regularly and in many cases result in compromise or loss of something valuable - data or money.


So how can we motivate change within these programs to make them more interesting?

I propose the following items as possible program improvements:

1. Tailor the program toward the audience or role. This is a concept already implemented in every program that I've ever audited. What has not been done is to allow the content to tell a story of relevance. There is currently plenty of historical data for use in developing a training program that makes the attacks more relatable and therefore of concern. Allow history the opportunity to enhance your programs relevance by role.

2. Current programs tell users some of the key things to look for in identifying email attacks of any kind. What they sometimes do not do is show the user where and what those things are. We have to remember as IT professionals that not everyone works in our field.

3. Develop some form of accountability towards the success of User Awareness programs. It is key that management support enforces this, which is one of the reasons programs are not very successful today. I see it all the time. Folks just see the program as "in the way" and all they want to do is "put the check in the box". Cultures are created and people are typically resistant to change. That makes this point fairly hard to overcome.

4. Social Engineering done well spans more than a single person. We need to develop not only methods of identification of social engineering one on one, but also make it identifiable as a collaborative effort across the organization. I'll admit that I do not have much insight on how to actually accomplish this, but in at least three of the attacks I recently read about it was obvious that several avenues were taken. Were they able to have been correlated these attacks may have been unsuccessful.

This most certainly is not an all inclusive list, but it does represent some of my immediate thoughts on how to improve User Awareness programs to combat Spear Phishing and other Social Engineering attacks. A great User Awareness program is really the strongest way to protect an organization from Social Engineering methods.

Secuirty in Web Applications

Howdy folks! I would like to assure my audience that SecuRelevance is alive and well. It has been 5 months since my last post due to some family and job priorities taking precedence. My goal is still, and has always been, to research and post topics every two weeks. I believe that I am finally in a position to do that again.

With that said, let's start the first post for 2015.

I was doing some research tonight when a thought occurred to me. Many applications have shifted to front end web applications and back end databases over what I would guesstimate to be about the past eight to ten years. As I recall it was approximately the first 3 or 4 years of my career that most applications in use relied on a desktop console, so I would imagine this timing to be about right.

I've heard a lot of hullabaloo over web applications and security with regards to things like Cross-Site Scripting (XSS), Cross-Site Forgery (CRSF), Input Validation, and SQL Injection to name a few. But one area that just dawned on me is the underlying architecture that so much of a web application is dependent on - things like .NET, or the languages and their libraries themselves (e.g. - C#, C++, XML, or Java). What about the webserver itself? IIS, Apache, or Tomcat to name the most popular selections. There are a lot of underlying parts that are susceptible to compromise. That brings me to my next point.


Now that we have identified that there are many underlying parts to the architecture, what about the lifecycle of a web application? In so many instances of web applications we see where they were developed at a point in time, and as such have been hardcoded for specific versions of things like, probably the biggest offender, java. In some other cases the product is limited to what was available at the time of its development. Because of this it lacks any compatibility with future releases of things like .NET upgrades, for example, which roll-up multiple security flaws, until such time that the applications maintenance life-cycle addresses it. This incompatibility forces the system to remain vulnerable until such time that a patch can be developed and released within the lifecycle, which forces a more controlled release of a remediation program because of the potential adverse effect on availability. If it is known incompatible, nobody wants a broken web server, especially not one performing a critical business function. Hmmm....now if I'm the hacker which do I want to attack?


Some would argue that a centralized patching and remediation program would cure these issues once a patch is released. However, in my experience I have noted that most organizations that have switched to centralized patch management for efficiency and cost savings, also suffer from the trade offs or consequences. A program with a good patch management system would probably not be susceptible to this right? Or would they...? What I have witnessed is the birth of a business culture that relies heavily on the central remediation, but does not necessarily check up on the agent health of the centralized solution. Perhaps the most dangerous part of this culture is that most organizations are geographically separated without much representation to support the centralized services. Even a mature patch management process would struggle in this environment.


Now let's look at a similar, yet different aspect of patch management. It's what most like to call the rack & stack effect. Management never wants downtime of a critical system. So what are your options? Well, if you have built in failovers, clustering, or other mechanisms of the like built in you could remediate each system independently, but if you cannot do that, then you are stuck with a server that is vulnerable until its patching window becomes available. The most common schedules that I've seen for the racking and stacking of patches ranges from 1 month to quarterly.


Now what I want you to do is think about these last two paragraphs - the pitfalls of centralized patching coupled with the inability to patch critical servers on demand. Now I want you to couple those two possibilities with all of the underlying framework architecture associated to a web application and ask yourself......Am I vulnerable?


Now sure there are still several additional measures of security at play here. For example a reverse proxy is probably in use to protect the webserver as are firewall rules and internally limited to specific trusted hosts even. A good defense in depth program would certainly thwart or mitigate the potential for compromise, but never-the-less I wanted to implant the thought into your heads and get you thinking that perhaps the best approach is a holistic one.

Risk Management Frameworks

Risk Management is receiving much more emphasis in security today than ever before. Risk Management certainly is nothing new, and has existed in many different forms over the years. I remember when I was in the Navy around 1997 I was first introduced to Risk Management in the form of ORM - Operational Risk Management. Having recognized this trend, I decided to study and test for the ISACA CRISC certification this December. You can find the basics of Risk Management through my blog, but this is a much deeper subject than what I have posted. To completely understand Risk Management an intense study is required. Just to put that into perspective a little bit, the CRISC manual is ~400 pages.

ERM is probably the most popular form of Risk Management. Various models exist for ERM such as CAS, COSO, and OSI's ISO 31000 and 31010. Tools like OCTAVE, developed by Carnegie Mellon and released in 2001, are also useful in identifying risks as well as the FISMA Risk Management Framework.

ERM is also being imposed upon companies by U.S. law in several cases. Sarbanes Oxley is just one such case and requires risk management in support of identifying fraud and fraudulent transactions. Even setting legal requirements aside however businesses are seeing increased value in earlier identification of risks and implementing risk management frameworks.

Risk can exist on many levels. There is overall risk to an organization as a whole, which may or may not be shared in common with each division, department, or work center. Because of this it is important that all risks are identified, cataloged, and reviewed regularly.

Risks are constantly changing which makes them dynamic and hard to track. Because of this risk must be evaluated regularly. Annual or semi-annual reviews should be conducted. Risks should also be evaluated immediately upon any significant change. This could be changes in market conditions, changes to an IT system or infrastructure, moving offices, and a variety of other possibilities.

Perhaps the most beautiful thing about Risk Management is its versatility. The topic itself is very broad and applies to many things while the principals used are always the same. One visit to RIMS and you will easily see that risks vary broadly from credit ratings, to terrorist threats, to newly identified software threats, and even risks associated to various processes. I think it is safe to say that Risk Management is here to stay, is still in its infancy even though it's been around a while, and represents a promising career for anyone interested.