Tuesday, September 20, 2016

Security vs Compliance...

This is a blog I initially published on the HPE Grounded In The Cloud blog.  You can see it here.
  
A good friend and colleague once said: “You can have security without compliance, but you cannot have compliance without security.” While that may be a bit simplistic, it does hold a measure of truth. But the question for many IT manager and executives is which one should come first. The simple answer is that you can have both, but it may require you to shift the paradigm.

There has been several occasions when I have been asked about this (as recently as last week at the HPE Protect security conference), so let me share some of the questions, as well as potential answers...

You can find the remainder of this blog here:

https://community.hpe.com/t5/Grounded-in-the-Cloud/Compliance-in-the-Cloud-Security-vs-Compliance/ba-p/6900359#.V-FB1vkrKbg

Monday, September 19, 2016

Data Locality - A Solution?

This blog originally appeared on my Medium site on April 26, 2016. It was also shared with a number of different LinkedIn groups, and generated hundreds of comments.

PREFACE: While I believe that this is already understood, please understand that the opinions expressed in these stories / posts / blog / whatever you want to call them — are mine, and not necessarily the opinions of my current employer, future employer, former employer, or anyone else that has (or does, or will) contributed to my income or livelihood.

To get everyone up to speed (and this is a repeat of the summary I have provided before) — In October 2015, European Court of Justice invalidated the Safe Harbor agreement, requiring the European Commission to revisit the regulations between the EU and the United States. In February 2016, the EU and the US had reached an agreement (called the Privacy Shield) to address the concerns that invalidated Safe Harbor. Two months after approving the Privacy Shield, regulators in the EU have come out and stated that the agreement still did not provide adequate privacy guarantees to European Internet users. Specifically, the concerns revolve around how data is stored and used by social media and search companies. The end goal of the European regulators is to have an agreement in place that forces US based companies to treat and protect data much in the same way that it is treated by the EU countries.

In short, the Safe Harbor and Privacy Shield regulations make up a portion of the laws and controls that are central to the conversation about data sovereignty. Data sovereignty, then, is the discussion around how data that has been converted into some digital form is covered by the laws and regulations in which it is located.

So, with that out of the way…

I was fortunate enough to sit on a panel a few weeks ago on the topic of data sovereignty. The same occurred again last week, this time, in New York. Both panels — and specifically the panelists that spoke with me — were excellent. An idea was presented at the first panel, and discussed again at the second, around the sub-topic of data locality: specifically how, and more importantly — where — data is stored, and the requirements and regulations that differ depending on the country in which the data is stored.

Let me start with a non-technical narrative (one that my mother can probably understand) — a simple Master padlock, probably much like the one you had on your locker in high school:

Author’s note: never keep both lock keys in the same place…

Not a complicated device —pretty much everyone has used a padlock at one time or another. You insert and turn the key, and the locking hasp unlocks. To relock it, simply engage the hasp back into the padlock. As long as you engaged the lock correctly and didn’t lose the key, your locker remained relatively secured (I am sure there are many high school locker tragedies, but you get my point).

When school was over for the year, you could take the lock off of your locker and could use it during the summer for your camp foot locker or the locker at the pool. The lock would still work fine, despite the change in location, so long as you had the key. Regardless of where you took the lock, the lock would function as you would expect it to — so long as you kept the key.

If you were like most, and took the lock home after the school year, only to find it in a junk box years later with your 9th grade Trapper Keeper, you would likely not remember the location of the key, rendering the lock useless. A padlock without a key is useless.

In summary:

  • You can use your padlock to protect things (like your locker or camp foot locker), regardless of the location.
  • The lock would work fine, regardless of the location, so long as you had the key.
  • The padlock without the key — regardless of the location — is useless

Applying the narrative to the technical world, and specifically the data sovereignty discussion:

Nearly all data (the lock) has the ability to be encrypted (the key). Regardless of the location where that data is stored (high school locker or camp foot locker), so long as the data remains encrypted, the data remains protected. Put simply, if the data is encrypted correctly, and the key is kept secure, does it really matter where the data is stored? Isn’t the data useless without the encryption key?

In summary:

  • You can use encryption to protect your data, regardless of the location.
  • The data would be protected, regardless of the location, so long as you had (and properly protected) the encryption key.
  • The data without the encryption key — regardless of the location — is useless.

One of the major components of the data sovereignty / data locality debate is WHERE data is stored. But shouldn’t the discussion be more about where the encryption keys for the data is stored and not the data itself? Properly encrypted data is practically useless without a method of decrypting the data(*).

Establishing controls for encryption key management are information security 101 best practices. So the narrative for data protection should be around how encryption keys are stored, where keys are stored, and how the data is being used once it is decrypted. Where encrypted data is being stored will make very little difference from a technical perspective.

This narrative is still evolving: there is no case law or legal challenges (that I know of) presenting and defending this perspective (yet). But there likely will be, and provided that technically minded jurists litigate the case, a reasonable (and logical) technical solution will find that data locality is irrelevant, so long as information security best practices around key management are enforced.

And I welcome further conversation about this specific concept: does it really matter where encrypted data is stored?

As for the data privacy and data use concerns at the center of the data sovereignty debate — well, we still have a long way to go on that front.

(*) Yes, I fully understand that there are some NSA / government types with massive compute that can probably break 256 bit encryption on demand, but I am not likely trying to protect my data from them. Nor *CAN* I protect my data from them…

World Password Day — Password Best Practices…

This blog originally appeared on my Medium site on May 5, 2016.

To “celebrate” World Password Day, I thought I would take a moment and share some information about password best practices. But first, a quick story:

During a recent security audit by a company, it was found that an employee was using the following password:

“MickeyMinniePlutoHueyLouieDeweyDonaldGoofySacramento”

When asked why she had such a long password, she rolled her eyes and said:

“Duh! The password policy says it has to be at least 8 characters long and include at least one capital.”

Yes, this is a nerdy security joke (or is it really a joke?), but we all struggle with the multitude of passwords that we have to remember on a daily basis. Despite that, it is still important to create passwords that are complex (strong) enough to thwart would be hackers. Here are some guidelines to consider when creating passwords:

● Passwords should be a minimum of eight (8) characters in length and use a mix of upper case, lower case, numerical characters and special (punctuation) characters. The industry best practice is to use at least three of these types of characters.

● Passwords should be changed on a regular basis. For very sensitive accounts or very exposed accounts, you should consider changing the password every 90 days (this is the best practice). Some accounts can probably stand to be changed a little less often, but it is often better to change all your passwords at the same time (or at least I find it is easier to keep them straight that way).

● Make an effort NOT to reuse your previous passwords. Reusing passwords makes it just that much easier for the bad guys to guess it. Also, try to make it a completely new password. How many of you have changed your passwords from “Password123” to “Password234”? You know you are out there… ;-)

● Consider what information is available about you on the Internet (think social media pages here). Creating a password that is your child’s name and their birthday is probably not the best. Pet’s names, family names, and special dates (birthdays, anniversaries, etc) are all pretty high on the list of things that I would try if I needed to “guess” your passwords.

● Patterns are not so great either. How many of you have the password “qwertyuiop[“? Can you guess where that came from? You would be amazed how many people use it. Along those lines, how many of you have an iPhone password that is “12345”? You know who you are, and I know several of you that use this as their password.

Passwords are generally a pain, and as we continue to expand our lives on the Internet, they will become more and more necessary for everyday tasks. As complicated as they seems to be, following some simple steps can make them more manageable, while keeping your personal information and privacy secure.

What Happens When The Empire Fails at Information Security…

This blog originally appeared on my Medium site on May 4,2016 in celebration of Star Wars Day.

To celebrate Star Wars Day, I thought I would share a few ways in which Information Security best practices where not adhered to by the Empire, and enabled the Rebels to win.

To be clear: I do not support the Empire, the Sith Lords nor any other types of scum and villainy. Nor am I trying to portray the Rebel Alliance is a weird, Force wielding, Galactic Hacker consortium or something. But had the Empire not been so lax in their security controls, Emperor Palpatine and his buddies might have been able to bring their “order and peace” to the galaxy.

Social Engineering: Social engineering is an attack that uses human interactions and plays on human weaknesses to break established security procedures.

Scene: Luke and Han, dressed as Stormtroopers, escorting Chewbacca to the prison block (Star Wars IV: A New Hope).

Lots of things going on here. First, no one wants to mess with a Wookie. So other were less likely to get involved when they saw that the Wookie was being escorted by two (only two) Stormtroopers. Luke and Han knew that if they looked like they knew what they were doing, they could walk around in plain sight without being questioned by anyone. Even after arriving at the detention block, the supervising guard did not suspect them as being bad guys, and only questioned them on a matte of paperwork. Sure, everything fell apart at that point — one of the security controls finally kicked in. But Luke, Han and Chewie were able to walk pretty much anywhere they wanted on the Death Star by exploiting social engineering flaws.

Lesson: People — not just the bad guys — exploit social engineering gaps every day. When was the last time you piggybacked someone into a controlled building? The really bad guys know this as well, using our politeness (holding a door open for someone) against us. It is extremely hard to break those habits, which is why your security guys are constantly reminding you about them. Who knows if the guy you are holding the door for is coming to blow up the building (or the Death Star)?

Identity and Access Management: Identity and access management is the system used by entities to allow and prohibit access to resources controlled by the entity.

Scene: Luke, Leia, Han and Chewie on the Shuttle trying to land on Endor (Star Wars VI: Return of the Jedi)

The Rebels have stolen (property theft, probably due to lack of physical security controls on the part of the Empire) a small Imperial shuttle and are landing a team on Endor to blow up the shield generator protecting the second Death Star. Apart from using the Imperial shuttle, the Rebels have also stolen a security code that will allow the shuttle to land on the forest moon. There are multiple points that the code could have been rejected, with the admiral even claiming that it was an older code. Eventually, the Rebels are given clearance and allowed to land.

Lesson: Identity and Access Management is a difficult topic for most businesses. Larger business MUST have a solution for IAM in place, as their employees turn around much more frequently than smaller companies. And unfortunately, there are always gaps — the employee who was terminated months ago still has an active security badge, because the two system are not connected, and the administrator of the badge system was not notified (or on vacation or whatever) that the employee was no longer with the company. All business need to have controls in place and audited regularly to make certain that there are as few gaps as possible.

Data Security: Data Security is the methods used by an entity to protect all manners of data from those not authorized to use it.

Scene: Princess Leia and her crew intercept the technical plans to the Death Star (Star Wars IV: A New Hope)

The very first scene in the very first movie (yes, the original Star Wars will ALWAYS be the first movie to me) starts with an epic space battle — the Empire is beating up a Rebel blockade runner that happens to be carrying Princess Leia and the technical plans or the first Death Star. The Rebels had intercepted those plans, and the Princess was in the process of delivering those plans back to her home world when she was captured. The Rebels had been a thorn in the side of the Empire to that point, but now they had the data necessary to severely cripple the Emperor’s plans of galactic domination using the Death Star.

Lesson: The Empire should have done a better job of securing the plans. We don’t know if the data was encrypted or not (another tenant of data security), but even if it was encrypted, it was transmitted using an unsecured methodology, allowing the Rebel Alliance to intercept them (and break the encryption, if necessary). Most companies and entities have intellectual property / trade secrets / military secrets that they don’t want others to have. Not only should that data be encrypted and protected, but the networks and devices that send and store the data need to be protected as well.

Some of these examples are a bit convoluted, and I am sure there are some out there that would like to debate the finer details of exactly what happened in the movie (message me — we can talk specifics ( I had to amend some things for brevity’s sake)). But the point is that Star Wars Day is just another opportunity to remind you (and your employees and everyone else) about the importance information security has on so many aspects of our lives. If Star Wars makes that point a little more enjoyable, then I’ve accomplished that goal!

Enjoy the day, and “May The Fourth” be with you!

The Path to a Cybersecurity Career…

This blog originally appeared on my Medium site on April 18,2016.

For quite a while now, I have been thinking about the lack of real world technical training in colleges and universities. Then, I see the story from CloudPassage that basically confirms what I have thought all along, at least in regards to information security — that most of the top colleges and universities DO NOT pay attention to cybersecurity in any way, allowing today’s computer science grads to receive their diploma without ever taking a class in computer / information security.


(You can read the link or check out the infographic if you choose — I am not going to rehash their study, except to say that it contributes to an alarming trend in the information security industry.)

I belong to several LinkedIn groups on information security, and one of the continued topic is how does one “break” into (no pun intended) the information security career path? As the article above demonstrates, the best colleges and universities will likely not help you. So the best I can do is share with you a few ideas how I think one might be successful in information security, mainly the path I chose to get the InfoSec career that I have.

Johannes factotum (Jack of All Trades, Master of None)

For every aspect of information technology that someone interested in an IT career can learn, there is a parallel subset of information security. Gaining experience in networking, systems architecture, systems administration, database administration and storage infrastructure is a critical starting point. From there, learning physical security, regulatory compliance, and encryption become easier, mainly because you have a foundation to build from. Trying to tackle complicated security controls necessary for some of the various compliance standards is nearly impossible if you don’t have a strong background in the “basics”.

Certifications

Arguably, the moment you start down the IT career path, you should invest in technical certifications. CompTIA offers some excellent, vendor agnostic certifications (thinking A+ and Network+ here), and those will help you get in the door. Once there, you can decide on some vendor specific certs, like those from Microsoft and Cisco. After that, and after you have gained about 3–5 years of experience, you need to decide how to specialize in IT –if it is InfoSec or some other niche specialty that you want to concentrate on. In the InfoSec world, there are a number of specialty security certifications — vendor specific ones from Cisco, Microsoft, and others, and vendor agnostic ones from SANS. But the best general information security certification — and arguably the most difficult one — is the Certified Information Systems Security Professional (CISSP). The CISSP is the “gold standard” of IT certs — respected by pretty much everyone in every business vertical — for the skills that the certification represents. It is a bear to get (at least it was for every single person I have ever talked to about it, including myself), but it opens nearly all of the information security doors.

Constant continuing education

Information security is rapidly changing. The great part is that it is constantly evolving, providing interesting new challenges and directions. The bad part is that it is constantly evolving, proving excruciating challenges and problems. Information security types always have to keep up, through continuing education or self-study. There are great conferences available to get the latest, but they tend to be a bit spendy. Most of the higher end certifications discussed above require you to maintain your certification through continuing professional education (CPE) credits. Keeping track of your CPEs can be a challenge in and of itself, but worth it, considering the alternative is to let your certification lapse (a friend of mine let his CISSP lapse and was punished by having to retake the CISSP exam. The guy had been working InfoSec for 10+ years, and still failed it the first time when he had to retake it).

I hope the major university programs clean up their act when it comes to information security training and education. But even if they do not, the path outlined above requires very little in the way of formal university training, and will lead you to an eventual information security position.
I am not one of those guys that believes that the sky is falling — not even close. But the InfoSec career path is a little different, and those that are trying to become a security professional often have a difficult time navigating their way through the different expectations. But in the IT industry, the demand is extremely high for these kinds of professionals, and shows no signs of slowing any time soon.

Best of luck, and ping me if I can help!

NOTE: I am not a developer, nor do I play one on TV. While the experiences are helpful and the advice is relevant, it is more focused on a traditional IT route, instead of programming. Programmers and developers should concentrate on programming best practices and foundational programming security. Having experience in the “hands on” IT world will only help a developer / programmer better understand the things they are programming for.

Sunday, September 18, 2016

Old Skool...

Welcome to The Security Beard!

There will be a ton of original content coming here in the future. But until then, I wanted to share some of my favorite blogs that I have written in the past few months, mainly from my Medium blog. Stay tuned for some additional content soon!

A friend and colleague of mine recently mentioned that I was “Old School IT” — actually several times. I have been thinking on it most of the weekend, and thought it might be worthwhile to share some of those thoughts.

Let’s start with a definition: In this case, old skool refers to a technology enthusiast that probably has 20+ years experience, and, at one point in their careers, has pretty much seen and done it all when it comes to information technology: system administration, wire monkey, help desk, network Jedi (or Sith, depending on your affiliation), database admin, and/or printer paper filler. You might have even had that title-of-titles: COMPUTER GUY.

In all likelihood, at this point in their careers, they are a specialist or expert — having done many of the various aspects of IT and settled into a specialty (for me it has been information security, or — even more specifically — information security and compliance in the various cloud architectures).

They may even be a member of management — using those skills gained over the last decade plus to educate and train others in the technical field. In some rare cases, the old skool tech has become an executive, using their experiences to drive a technical vision and direction for an enterprise or the industry. In my years of tech, I have been privileged to know and even work with a few of these. It is a truly amazing thing to see experienced technical innovators at work — the right combination of business acumen with technical kung fu.

Now to really age myself — Part of being old skool is remembering and working in a time where technology was NOT ubiquitous, the Internet was a very small collection of web pages, and the only thing that Apple had released as a portable mobile device was a Newton (and no — a Mac Portable does NOT count).
15 years too soon, Steve...
Point being — I remember the trial and error in building computers (jumper combos and dip switches), programming EPROMs, coding using the VI editor in some flavor of Unix and making a Macaquarium out of my Mac SE/30 (still wish I had that thing). Answers came in books and manuals (RTFM), not Google searches (anyone remember setting up Sendmail using the Bat Book?). It isn’t to say that the twenty somethings that are the techies of today are not qualified, but it is a very different beast than it was when I started (one could say the same thing about programming with punch cards or even worse — in Fortran — but I am not THAT old).

Being old skool has made me a better technologist: instead of jumping into management and executive positions with no experience, I have been there and done that in the technical world. I can honestly relate to those that I am talking to at *ANY* level. A significant part of my job is talking to people about cloud security, and I have the confidence and the experience to relate directly to the audience — from the C-Table to the security engineer — because I have been there and done that. For example, when attending a technical conference, which was better: the sessions where someone drones on and on about technology (think PowerPoint of Death), or the sessions led by someone who is a technical expert in his/her subject (think technical demos or just Q/A)?

I never really intended to have a career in the technology industry — it just sort of happened. But I kept coming back to it, despite diversions in politics and non-profits. Sure, it pays the bills. But there is more to it. The constant challenge of learning may not be unique in any particular vertical, but in the technology world, and even more so in the information security and cloud spaces, the technology and uses are evolving right in front of us.

Old skool technologists — then — are those that have evolved as the technology has evolved. They have stayed relevant with their skills, applying their experiences to better understand the next evolution — revolution.

I am proud to be considered old skool…

(BTW — I am not so “old school” as to not know how it is really spelled…)