Don't fear the command line...

Many of us grew up on Windows.  It's not like we chose Windows, it's just what was there.  While I really don't care much for Windows anymore, I will admit that there are some convenient features in the operating system.  I can't think of any...but I'm sure there's one or two...

Anyway, Windows has turned us all into GUI-babies.  Everything we use has some sort of interface where we just point and click on options.  We don't really have to tell the program what to do, we just choose from some canned, square-shaped choices.  It's easy, and easy is good.  After all, computers aren't supposed to make our lives more complicated, they're supposed to make them easier.

The first time I really had to work with the command line was when I was taking a C++ class.  Most of my coding, compiling, debugging, etc. was done through a putty interface, connected to a remote linux host.  I cut my teeth on very basic commands, like moving through directories, creating folders and files, and changing permissions so I could just get something to run!

Over time I picked up a few more skills, and started forcing myself to use VIM instead of GUI-based text editors.  VIM stands for VI improved.  I don't know what VI means.  Eventually I was able to navigate proficiently through linux operating systems, creating and modifying files with ease.  I thought I was becoming a proficient linux user.  Ha...

Then I started working here.  I was introduced to things like 'grep', 'awk' and 'cat'.  I learned how to parse through documents using only the command line.  I learned out to launch and use applications without a GUI, like nmap.  I started writing code and configuring servers all inside the terminal window.  Even after all of this, I still feel like a newborn when using a linux machine.

That's not to say I'm not confident in my abilities to use linux or the command-line, but I've come to realize that there is just so much to learn!  The key is not to be intimidated.  There are still times when I spend way longer than I should trying to figure something out, which is fine.  That's how you learn.

As frustrating as it can be sometimes, I've gotten to the point where I think I'd rather use the terminal window than some fancy GUI, and that might sound silly, but I like it this way.

CBT Nuggets

A common first step for most new jobs is some kind of a training plan.  While employers will obviously expect you to show up with a baseline foundation of knowledge, they can't expect you to know everything on the first day.

I'm pretty fortunate in that the folks I work for have gone above and beyond to develop an onboarding program, and to insist that I not be overloaded with responsibilities before I'm given the opportunity to learn some of the basics of our trade.

The training program includes a series of lab exercises, all of which to be conducted against a fully-functioning lab network comprised of physical and virtual machines.  The exercises are designed to help me develop skills that will be directly applicable to the consulting work we do.  For example, one of the lab exercises covers nmap, a popular (if not the most popular) network discovery scanning tool.  The lab goes over basic commands, arguments/options, output formats, and how to analyze the results with command line parsing tools.

While these exercises will help me perform assessments, they've also purchased a subscription for me for the computer-based training website, 'CBT Nuggets'.  CBT nuggets has a plethora of extremely useful courses.  So far I've taken courses on basic networking, to include IPv4 subnetting, DNS basics and configuration, and network topology.

The instructors for CBT Nuggets are very enthusiastic and knowledgeable.  I can't say that I have ever been a fan of computer-based training, and I still have a little trouble after lunch (Zzzz...Zzzz), but CBT Nuggets is about as entertaining as it gets (comparitively speaking).  Not only that, but learning via CBT nuggets is very self-paced.  If I have 8 hours to allocate to training, I can go through as much content as I want in that time.  If I feel like I have a handle on something then I can move on, or if I feel like I need more time then I can just rewind.  You can even speed up and slow down the videos!  I find that I'm able to watch most of the videos at 1.6x the normal speed and still process the information.

I'm not entirely sure how much we're spending for the CBT Nuggets subscription, but I can attest that it's well worth the money.  Anyone struggling with any area of IT, and has a desire to learn and get better, should definitely check out CBT Nuggets.

https://www.cbtnuggets.com/

OPM Data Breach

I wrote a piece talking about the Office of Personnel Management data breach to serve multiple purposes, one of which is to share it with all of you ;)

LESSONS LEARNED FROM THE OPM DATA BREACH

July 16, 2015

Information security is a lot like an umbrella; the need is not apparent until it starts pouring. As malicious Internet activity increasingly threatens organizations all over the world, it is becoming more necessary that business leaders alter their perception of what an effective information security program should be. The most recent data breach of the Office of Personnel Management (OPM), which exposed sensitive data of over 20 million people, clearly highlights valuable lessons in information security that we cannot afford to ignore.

Don't ignore the signs

“This has been going on for years, and it's inexcusable.”

-Rep. Jason Chaffetz, Chairman, House Oversight & Government Reform Committee

The Inspector General (IG) for OPM is responsible for annually reviewing the agency's compliance with Federal Information Security Management Act (FISMA) standards. The House Oversight Hearing on the OPM Data Breach detailed many of the findings made by the Inspector General in recent years:

• FY 2007, the IG rated OPM's data security as “a material weakness” due to a lack of IT policies and procedures to safeguard information
• FY 2009, the IG expanded “material weakness” to include overall agency information security governance programs, which incorporated the information management structure, all resulting from a lack of necessary leadership, policy and guidance
• FY 2010, the IG states “we continue to find the [OPM] information security program insufficient”
• FY 2011, the IG again states “we continue to believe the information security governance represents a material weakness of the IT security program”
• FY 2012, the IG reported that the Office of the Chief Information Officer (CIO) “continued to operate with a decentralized structure that did not have the authority or resources available to adequately implement new policies”, and highlighted “numerous information security incidents”
• FY 2013, the IG finds that “OPM's decentralized governance structure continues to result in many instances of non-compliance with FISMA requirements”
• FY 2014, the IG reports that “11 major OPM information systems are operating without valid authorization. This represents a material weakness in the internal control structure of OPM's IT security program”

The Inspector General's reports further elaborate upon the gross negligence responsible for the data breach earlier this year, even after eight years of scathing reports. This is a prime example of how ignoring the signs can have devastating consequences, especially when lack of leadership and guidance are principally responsible.

Be proactive, not reactive

Following the OPM data breach, the White House announced a 30-day initiative that they're calling a “cybersecurity sprint”, which is designed to address the most critical vulnerabilities across the Federal government's agencies._[1]

Gregory Wilshusen, Director of Information Security Issues at the U.S. Government Accountability Office, responded discordantly to the White House's effort by saying, “It's not a sprint -- it's a marathon." He further stated that there needs to be a fundamental shift in daily operations that places more emphasis on security, to include the continuous monitoring and assessment of controls._[1]

A truly effective security program is not merely reactive, but instead attempts to detect and prevent threats before they can exploit vulnerabilities. Companies should invest in their security programs as early as possible so that they have time to grow and mature along with business needs and capabilities. This requires leaders to find the right people, develop the right processes, policies and procedures, and to implement the appropriate technology before a devastating attack occurs.

There is no single point of failure

Katherine Archuleta, Director of OPM, resigned on Friday, July 10 as a result of the attacks that took place between March and April 2015. Her resignation was called for by many high-ranking government officials, to include President Obama._[2]

“I don't think we can expect that a change of a single person can be a satisfactory answer to the problems at OPM”, said Representative Adam Schiff of California, who serves on the House Intelligence Committee, in response to Ms. Archuleta's resignation. He continued, “...if there's a problem at one agency, there's likely a problem at other agencies.”_[2]

There tends to be an attitude that a single point of failure is to blame for information security incidents. While the OPM breach resulted in the departure of the Director position, this single point of failure is typically manifested in organizations by the Chief Information Security Officer (CISO), whose average tenure will not last longer than 2.1 years according to the Ponemon Institute. This is because the most immediate reaction for most companies to a security incident is a 'changing in the guard'._[3]

Along with this change of the guard comes unrealistic expectations. Security programs take time to implement and mature, but business leaders too often expect more immediate results. This contributes to a growing sales market of first-year CIOs and CISOs. For the former, the top 25% spend over $1 million in their first year on the job._[3]

We often say at SDGblue that 'strong personnel can compensate for weak technology, but strong technology cannot compensate for weak personnel'. Spending $1 million every two years on new hardware, software and services will not necessarily solve a company's IT needs, but investing in a strong team and providing them the resources necessary to properly secure an IT infrastructure will pay dividends in the long run.

[1] Corbin, Kenneth. How OPM data breach could have been prevented. CIO. July 13, 2015. http://www.cio.com/article/2947453/data-breach/how-opm-data-breach-could-have-been-prevented.html

[2] Davis, Julie Hirschfeld. Katherine Archuleta, Director of Personnel Agency, Resigns. New York Times. July 10, 2015. http://www.nytimes.com/2015/07/11/us/katherine-archuleta-director-of-office-of-personnel-management-resigns.html?emc=edit_na_20150710&nlid=66044131&ref=cta&_r=0

[3] Schuck, Henry. High CIO and CISO Turnover: What it Means for IT Sales. DiscoverOrg. Feb. 5, 2015. https://discoverorg.com/blog/high-cio-and-ciso-turnover-what-it-means-for-it-sales/

lxml

Brief update: I've finished a few of my data parsers that will be used to format the raw data into something easily imported into my database.  I've run into a couple of snags when it comes to the final output, but I'm definitely on the right track.

That said, none of it would have been possible without the lxml library:

http://lxml.de/

The lxml library allows you to do cool things with xml in Python.  For my purposes, I use it to do the following:

• build an XML tree object in Python
• parse and step through the tree to find specific data
• add this data to lists

Once the data is in lists, I can covert it to a csv format.  However, I've run into some issues with this and been forced to re-examine my approach.  Maybe I don't need .csv files.  Maybe I don't even need lists.

I'm going to put more work in and see how easily I could put the data back into an XML format, which can also be uploaded into a database.  I like the idea of putting it back into XML because it does not rely so heavily on this tabular, structured paradigm.  Not only that, but there's more brains behind the XML.  If I need to go back and trouble-shoot my parsings in XML, there are tools that can help me step through the data the same way they helped me create it.  .csv files leave me with less options after the fact.

Ultimately, I just need to get through the data as quickly as possible and get it into my database, but my own personal quirks are holding up the process.  This is because my code has to be as pretty as possible.  If I feel like I'm using too many (or just misusing) control structures because I've not thought everything through, it starts to look sloppy in my eyes.  The one thing about Python is that it really makes me want to write as few lines as humanly possible to achieve my goal.  That is, after all, what libraries like lxml are intended to help me do.  Why reinvent the wheel every time I need to complete a task?  Unfortunately, I do try to reinvent the wheel sometimes, and obsess way too much over making it as perfectly round as possible.

Social Engineering

Social Engineering, sometimes referred to as 'human hacking', is responsible for some of the most damaging attacks ever recorded.  Even aspects of Stuxnet were attributed to targeted social engineering operations.  Social engineering is dangerous because it revolves around the one factor in an organization that can't be predictably incorporated into a security program.

Or can it?

Just in case I've lost you, social engineering is the act of persuading a user to divulge information that may or may not be in their best interest.  For example, I could call, email, or simply approach someone in person and claim to be an IT professional.  I could tell them that their workstation has been infected, and that they'll likely get in trouble because this has occurred as a result of their 'abuse' of company network resources.  People might start thinking, 'oh no, I must have clicked on something on Facebook...', but will rejoice when I inform them that I can fix it before anyone has to find out.  All they have to do is give me the keys.

Most professionals and attackers will tell you that the easiest way to obtain someone's credentials is to ask for them.  If you ask the right way, you'll find that statement is surprisingly true.

I've recently become more interested and involved in social engineering assessments at the office.  Partly because I genuinely find it interesting, and also because we don't seem to have a resident expert.  We have a guy that's really smart on networking and program management, another guy that's a brilliant coder and pentester, but no one that seems to want to own the social aspect.  There's a lot to be said about finding a niche and becoming part of the team, at least enough to motivate growth.

So back to my original question; can the human factor be made predictable enough to secure an organization?  I think yes, but probably not the way you think.

Truth; just assume someone in your organization is going to be victim to an attack.  Don't 'if' about it and train like you're going to raise user awareness to a level that is immune to an attacker's charm and wit.  Someone is going to screw up and give someone bad the keys to the castle.

However, you can put other safeguards in place to detect, contain and remediate the effects of a compromised user.  In my opinion, the focus on awareness training should be less significant than the focus on mitigation efforts.  As I've said before, you put in sprinklers and do fire drills so that 'when' the fire occurs, you can react.  Information security should be no different.

Databases, Parsers, and Sprinklers

So, quick confessional: I've been so busy lately that I forgot about a deadline that I actually set in the first place.  That's the bad news.

The good news is I've made a lot of progress in the last week and a half.  Regarding my final project, I've created an Entity Relationship Diagram (ERD) that maps out all of the tables, their fields, primary and foreign keys, etc.  I used a tool called MySQL Workbench, which is written by Oracle for MySQL users.

https://www.mysql.com/products/workbench/

It's pretty great if you're going to develop databases to be used in production, but it's also just super-rad if you need to design the schema and then reverse-engineer some SQL.  I used it for the latter.  I'm now at a point where I think I can begin working on my Python parsers to put the raw XML data from our network discovery and vulnerability scans into a format more easily imported into a database (most likely .csv).

Aside from that, we've been working on a new project at the office.  I don't think I can talk much about it publicly right now, but the guys that I work for are incredibly smart and are onto something big that will likely change the way people look at security in the area.

This brings me to an observation that I've made since starting with this security consulting company; there's a lot of people that probably don't care enough about security.  I understand that it's difficult to maintain perspective when you take on a specialization.  All of the network engineers probably say, 'we don't have enough people to manage these firewalls, and they buy us crap to work with!'.  The help desk specialists say, 'people don't care about the equipment or how to use it!  We need to spend more on training and better hardware!'.  Everyone probably thinks their specialization is a little more important than the rest.

That's how I've recently started to feel about security.  I don't understand why people aren't more concerned.  You install fire alarms and sprinklers to protect your physical assets (which are totally replaceable), but you won't lift a finger to protect your digital assets?  I use the generally 'you' here, which really means 'some of the companies I've run across'.

Granted, there are many clients that are very involved in the development of their security program.  These clients are motivated to receive assessments and get better.  That's the attitude everyone should have.  Unfortunately, I think some people won't learn until it's too late.

In other news, the only other thing worth mentioning is that I've been doing a lot more lately with Social Engineering.  I think it's very interesting, and I enjoy it a ton, but I'll save that for next time!

Hello, World!

Welcome to my University of Kentucky Information Communication Technology Internship blog!  The purpose of this site is to document my experience as an Information Communication Technology intern and discuss things I've learned through this experience.

While the grading period is technically June 11-August 6, I began working as an intern since late March of 2015.  I was accepted for an internship with Lexington-based technology company as a Security Analyst Intern.

My interview process was unorthodox.  I took a class with UK Computer Science Professor Dr. Ken Calvert in 2013, Network Security, and I met a guy in that course that was an intern at a technology security company.  I was intrigued by the many stories he would tell me during class of the fun things he got to do, and get paid to do!  Earlier this year my friend reached out to me and let me know that his company was looking for interns to join their security team.

I sent him a resume and was called for an interview.  My interview was a luncheon at a local pizza restaurant, where the entire security team and I sat at a table and discussed security related topics for an hour or so over lunch.  I was rather nervous, but my friend had prepared me beforehand by giving me a list of topics that would be discussed as part of the interview.  I answered their questions to the best of my ability, and within a week I had an offer!

Perhaps that isn't so unorthodox, after all.  Most jobs that I've had came about by knowing someone that could help me get a foot in the door.  I suppose you could say that this job had a lot to do with networking.

Networking.

That's a joke, but I digress.  I didn't have a tremendous amount of security knowledge going into the internship, but they re-assured me that all they required of me was motivation and potential.  If I could learn, they could teach me.

Thus, since starting with this company I've learned a tremendous amount about the Information Security industry.  I've learned to use network discovery tools, vulnerability scanners, write reports, and even aspects of social engineering!

You may have noticed, but I've decided not talk specifically about the company.  One thing I've learned about the corporate world is that they're not incredibly fond of unofficial mouth-pieces.  That's not to say that I've been forbidden to discuss details of my internship as part of the ICT 596 course, but let's just suffice it to say the following (and then just move on):

• I'm an intern for a company that offers technology solutions.
• I work in a department that conducts information security assessments.  We consult clients on how to protect their information assets.
• There is a steep learning curve for this industry, and a lot to learn.  Although I've already been here for a few months, I am still very much in training. 

Instead of focusing on irrelevant specifics about the company for which I work,  I will instead try to talk more about some topics, processes and tools that I encounter everyday as part of my internship.  I look forward to documenting this learning experience so that others might be able to determine if security is something they, too, are interested in.