Showing posts with label Cyber Threats. Show all posts
Showing posts with label Cyber Threats. Show all posts

Tuesday, June 17, 2014

Augusta's HORRIBLE drivers and Network Insiders

I have been having this thought circling my overly-active...for about a week now.

I was driving home from the VA hospital last week, taking one of my normal, short routes to get home. One particular stretch of the road I was on has three traffic lights all within [about] a half-mile total. These lights are, naturally!!!, timed so as to make you stop at each of the three. However, there is one exception to the stopping rule: the "I don't care/I'm more important than anyone else on the road/It's my right/" attitude. At least this is what I personally believe is [at the least] a large portion of their attitude about red lights and what red lights mean.

To put it simply, as I pulled up to stop at the first of the three traffic lights, there was a fellow going the opposite direction as me who just had to make a left turn, despite the light having already been changed from Yellow to Red. Yup, this ignorant/selfish/lazy/stupid person ran the red light. However, that's not even the worst part about the bad HORRIBLE drivers around this town?

Granted, Augusta, GA certainly has [much] bigger problems then schmucks running red lights. However, the interesting, (and absolutely FRUSTRATING) fact here in Augusta is that at least ~90% of the red lights get run...this is my perception at least. This poses an additional need to be extra-vigilant, always watching ALL of the other lanes at an intersection and waiting at least five or ten seconds before entering the intersection (if you're the first car in your lane).

    A couple of quick points on the problem:
  • The driver running the light isn't really doing anything out of the ordinary, based upon the "normal" behavior of drivers in this area
  • But they are still breaking the law, trying to sneak by the rules and sneak by any cops (if the cops would even pull them over)

    A couple of quick points on possible fixes:
  • Have more cops (and make them write the tickets)
  • Have the cops learn what to watch for, especially in terms of that one 1987 Oldsmobile Cutlass that starts gunning it while still being 100' from the signal

By now, my three (if I have even that many) followers may be wondering: What in the world does the poor driving habits of people in Augusta, GA have to do with anything network related? The simple answer is: "Nothing."...Directly that is. But some certain things stuck out the other day that reminded me of a common network problem, so let me see if I can tie these two things together.

Can we think of all of the cars on the road in the city of Augusta, GA as representing user/machine activities on a network. For instance, one car could be used to represent a user transfering a file while another car could represent standard AD replication between multiple DC's. If you can think along these lines, then I believe it will be easy for you to make the same leap that I did.

When I was thinking about all of these cars in the turn lane, I came to the conclussion that they could be placed into two distinct catagories, despite any number of small, and large, differences in either the vehicle(s) or the driver(s). These two catagories are: safe drivers, and unsafe drivers. Now, think about what they are doing: they are making a turn, the same turn, roughly going the same direction (although the tires of each car may not follow the exact arc of another).

Now, and my brain did this auto-magically so I might be wrong, but it's not a far leap to translate the drivers of each car into "Users." As the drivers are all driving, the "Users" are all..."using"...a network, a resource, a device, etc. This is the point in my thinking were I came to draw a correlation from the drivers making the turn to one of the biggest problems we face in network security: The Insider! So who is the insider in my analogy and can this do ANYTHING for me, or others, in terms of finding that insider?

Who is the insider in my turning cars analogy: It's easy....it's the baby in the backseat! ...just kidding. The insider is represented in this analogy by the idiot jerk, or even JERKS, who run the red light instead of waiting for the next green light. Those that made the green, and even yellow, lights are the users performing "normal," authorized activity on the network. Maybe that driver who forces the yellow and it changes while they are still in their turn, that driver could possibly be lumped in with the jerks who just run the red light. Your call there, because I honestly don't know that it matters to my overall thinking here.

So I have told you all about the poor driving in Augusta, GA and about how I easily correlated that into network activity, especially the inside threat. Now what? Here is where my head started to hurt the other day. I wonder if an algorithm could be defined to identify those who are GOING to run the red light, before they run it...or as soon as they put more pressure on the gas pedal? If this could be done then I believe an algorithm can be created to better identify an insider threat...maybe not as early as when they are just "thinking about it" or testing their access, but at least as early as the start of that first file transfer or copying action. Thinking about this has led me to some other thoughts regarding protection from the insider (and detection?).

Budgeting for your company's security may be a difficult or even non-existent task due to financial constraints/availability. However, I wonder about some of the bigger equations and books that throw around terms like Risk, Mitigation, Return On Investment, etc. Do we not already have at least 50% of the needed functionality to start working towards identifying and/or stopping insider threats/breaches? Do we not already have at least 50% of the tools needed to turn those terms into action...to put our brain where are mouths are, so to speak?

Some questions/thoughts:
  • Can you baseline your network in terms of:
    • The average time window that each user is logged in?
      • If so, then why not block them out of all times outside of that window? Sure you may have someone stay later than usual on rare occasions, but in that instance they could conceivably call the help desk for a short logon time extension.
    • The average number of bytes each user sends [somewhere]?
      • Then users could be grouped and rules utilized for abnormal data sends.
      • For example, you baseline and find that ten of your users send less than 10MB of data via SMTP between 9:00a and 12:00p. A rule firing for 10.01MB of data transfered, or maybe even using a calculated tolerance (say, 10%?) would alert those monitoring said rules
  • Do we really have any excuses left to not start making better usage of access controls
    • Windows Group Policies and ACL granularity have improved a lot in the last couple of years
      • Would it be that hard to create a security group for only those allowed to access a particular file
        • AND apply time limits
        • If it's an Office doc, the Directory Rights Management provides even more help here
    • *NIX systems support finer grained access controls
  • Implementing a two-person rule
    • I envision something akin to the User Access Control prompt needing the credentials of an administrative user
      • As two-person rule, the credentials would have to be of someone else who is already authorized to access the material
  • Is user training really effective against the insider?
    • NO! Absolutely NOT!
I cannot be the first one to have any of these thoughts or to present any of these questions. I wouldn't be surprised if these thoughts and questions hadn't been floating around the security nerd cubicles for the past 20 years. I wonder though, are we, people in general, getting more and more complacent about what we do, what we see our office mates do?

Monday, May 5, 2014

Annual Simulator Training

I watched an interested episode of Nova with the family the other night. It detailed issues with cruise ships and their sinking and compared similarities between disasters such as the recent Italian ship in which the Captain hit a BIG rock, the Titanic, and the Oceanos. A large part of the comparisons dealt mainly with the ships and the Captains. However, part of the episode dealt with crew training.

In the aviation world, at least in the US, pilots are apparently required to take annual simulator training. Maritime crews and Captains are not. Neither are Network Security professionals. Wait. What's this about annual simulator training for nerds?

It's simple really...at least in my head; I admit that I may be foggy after having a Cinqo de Mayo dinner with the family at Chili's. But I think it makes sense, at least some sort of annual event for all types of network security folks, not just DoD exercises or SANS training courses....or even the rush to submit CPEs for your CISSP at the end of the cycle. I may be putting the majority of us nerds into the same container as I am personally, but here's my points:

1. I am frequently moving from one project to the next. Although some may have solutions in the same domain (pun intended!) as others, there is no one-size-fits-all, at least I haven't found it yet. In the last 12 months, for example, I have had to work out solutions using: flash, php, perl, python, bash, batch, PowerShell, new exploits and old exploits, etc, etc. Have you not had to do the same? I'm certainly not complaining, although it can be frustrating on job interviews if you haven't touched perl in 12 months and you get a specific question only to have the answer stuck on the tip of the tongue. :-(

2. What's old is new and what's new is old. While base methodologies and languages haven't changed a whole lot over the last decade, it's safe to say that solutions using said methodologies and languages, or some combination thereof, have certainly changed. Do you use the same type (or even the exact same) script for some task you've been doing over the last decade. I care to venture the answer is no...or at least I think it should be. For example, what I used to like to do in Perl or Batch/Bash scripts, I now like to do in PowerShell (and Perl and Batch/Bash). Some GUI tools even catch my fancy every once in a while. :-)

3. Who's the bad guy? He's not the same one he was decade ago. Probably not even the same he was a year ago (or it could be a she, to be fair!). Does the adversary (being he, she, or them) use the same tactics, techniques, and procedures...tools and methodologies as a year ago. Sure, beaconing will always be beaconing...but even this has changed over the years in terms of ports, protocols, services, encryption, data, etc, etc, etc.

4. Certification providers and requirerers (not sure that's a real world) have moved towards a demand for recertifying, annual training requirements, or a combination thereof. That's all fine and dandy and usually not that complex to satisfy. But, is it REALLY satisfying? If you took a SANS course last year just to learn something new and/or satisfy some CPE/CMU/C?? requirement, could you sit down today and perform even half of the tasks you learned. No...I don't think most people can unless that training was already a part of their job function or they found a way to incorporate it as such! Fact is our training and our knowledge, in any field really, is perishable. If you don't use it, you WILL lose it and that's the cold hard fact of the matter.

I have at least 15 different and specific skills/languages/tools listed on my resume. I can even talk to all of them to some extent. However, there is a number of them that I need to use the manpage for to refresh myself because of the perishability of the skills (and sometimes because the ever-so-slight differences between some scripting languages). I mention this not as a focal point of this post, but just a way to maybe bring the point home a little bit more, that we computer security nerds live a world that is as horizontal as it is vertical and our tools are as perishable as mayonnaise on the back porch on a hot summer day.

This brings me to the thought of "Annual Simulator Training" for computer security nerds. If we had, regardless of industry or threat, or better yet, tailored to industry and threat, an annual training on a simulator, wouldn't this in fact allow us time to re-learn, re-master, re-visit the tools we don't get to use often enough, or in ways that are challenging enough. I am sure that one of the two people who read this blog has already thought "Doesn't the DoD or USCYBER already do an annual training/simulation event?" The answer would be yes. However, the number of players in the "big" simulation is not a realistic sampling of the network security nerds inside the DoD/USCYBER complex itself. Not to mention, it's training only for this finite number of participants.

There are options available now in terms of simulation environments for network protection, detection, response, analysis, etc. But they are targeted to specific customers (read: If you have enough cash or credit, you can have a simulation network that works 50% of the time...if you're lucky!!!). Furthermore, as with the Captains and crews of marine vessels, there is no one specific requirement for annual simulation training in our field. True that there are the requirements of CPEs/CMUs and the opportunities that some individuals get based solely on there employment location and/or provider. However, I would argue that the private sector is as important as the government and public sectors in terms of how we are equipped to protect and defend. And if the level of importance is the same across the board, at least to all US interests (private, public, and governmental), then the training exercises and environments should be further extended to support annual simulation training for all of us network defenders and penetration testers! Furthermore, if these training capabilities were extended, this would allow for federal support/mandate of an annual simulation training environment.

Now, before anyone shoots me for thinking that I want the federal government to be "all up in our business," let me say this: I don't want them in our business, I want them to better support our business. I think in doing so, we all benefit regardless of sector. Furthermore, it might help stop some of the hair-brained, half-cocked, knee-jerk reactions that I see in terms of policy shifts and requirements development (why should baselines shift every time some CISO or some Colonel gets wind of some "new" threat?).

OK. I'm going to stop here and take a giant leap off of my soap box! Hope you enjoyed this episode (psychotic episode???) and stay tuned for a word from our sponsors. :-)