Peanut Butter Security

Ten Hard Questions About Security: Question 2

harperse — Fri, 27 Oct 2017 12:48:33 GMT

Question 2: Whose system is this?

Don't think this isn't a valid question for every system in your network. Every system. I don't care if it's a network device, or the system that fires off your sprinklers, if it is connected to your network and has been for any amount of time, chances are that some outside actor has had access to it in some way. Users, including some of the most trusted administrators in your environment, make mistakes:

They freely use their USB drives at public locations on computers whose provenance cannot be trusted.
They open attachments from untrusted sources.
They browse questionable web sites with insecure Javascript embedded.
They let their children use their work laptops.
They download freeware and shareware on a regular basis.

Actions like these don't necessarily guarantee that a compromise has occurred, but they greatly increase the chances. And with every action like this, chances keep increasing. The length of time a system exists in your environment also has some bearing on this question. Long life systems, such as Active Directory or any HR or payroll systems, have a greater chance of being compromised due to their high value. What is the answer to this conundrum? Privilege Management. The concept of privilege management is not new, but many of the mechanisms used in the past have not been complete solutions. Notice I didn't specify any certain piece of privilege management; many enterprises have some type of privilege management, including identity (PIM), access (PAM), and/or session. A holistic privilege management solution contains all of these components, working in harmony. But the privilege management solution is only as important as the system that gives it the real value: Auditing. A privileged management solution is only as good as the information you can glean from it. Yes, many of these systems are very handy, and they really look to simplify the management of privileged identities. But if they are not securing these resources, they are useless. And if the security behind these systems is not being regularly reviewed and filtered and scrutinized, then you have really added no value. System administrators are generally smart people; they don't need a point-and-click adventure to login to their servers. They don't need colorful dashboards to tell them to which servers they have access. They need to be ensured that no one else can gain access to their systems. I like to open discussions about privilege management with 3 key points:

Keys to the Kingdom
Quis Custodes Custodiet?
Assume Breach

You may recognize the second point as one of the questions from the introductory post. We won't go deep into that one in this post, you'll just have to wait. Let's start with the keys... "Keys to the kingdom" is an age-old phrase. It evokes thoughts of allowing access to all of the assets and secrets of an organization. When I hear this phrase, I immediately think of The Matrix, and the character called the Keymaker. His purpose was to give access to the programming hallways of the Matrix to the hero of the movie, Neo. And of course, many characters in the matrix were programs. Therefore, the Keymaker was the privilege manager of the matrix. And yes, I know that's a pretty far-fetched example (but it's better than the Keymaster and the Gatekeeper in Ghostbusters). Your privilege management administrators are no different than the movie character. Their job is to administer systems that allow only the authorized users to authenticate to specific systems, and to account for the access granted. That last sentence contained three very important words: authorized, authenticate, and account. Some of you may recognize the concept behind those three words now that you have seen them together. Commonly known as AAA (Authorization, Authentication, and Accountability), this concept is a fundamental building block of security. If you don't know who has access to any given system, you cannot claim to have control of it. Moral of the story here: limit the copies of keys to the kingdom. Your most trusted administrators should be a very small group of highly skilled, long time direct hire employees. Employees who have undergone and continue to undergo extensive background checks on a regular basis. Employees who are trusted and trustworthy, but tend not to trust others. Eternal pessimists. People who believe in the worst in people, including their own teammates. People who question everything. Their management, on the other hand, need to be the best listeners in your organization. Finding the right people is hard, but finding the right managers is even harder. They have to have the same attitude as their employees, but also have to believe them when they state that there is or may be an issue. They need to be skilled in security as well as being people managers. These types of employees can be hard to manage, and these types of managers need to be tougher than their employees. "Assume breach", on the other hand, is a mindset that some may consider rather paranoid. In security, paranoia is not necessarily a bad thing, but in reasonable amounts. You probably don't want a conspiracy theorist running your privilege management, but you do want someone who wants to go back and double or triple check their work to ensure that it is done correctly. You want someone who is willing to investigate an error that may look innocuous to some, but seems to stick out like a sore thumb to them. Where do you start looking for breaches? Start with your most privileged accounts. The greater amount of control a bad actor has to your environment, the more damage they can do. Limiting the number of those users, as stated above, is the best way to properly monitor them. If you have 500 enterprise-level administrators, the amount of data to parse through would be a full time job for a single team. Conversely, if you have 5 enterprise-level administrators, it's an easy task for one person every day or maybe even week. Concepts like the Privileged Access Workstation (PAW) help whittle these logs down even further. THe lower the number of data points to gather, the more successful you will be in finding your bad actors or breaches. Moral of the story for this one: don't just work to prevent intrusions, actively seek them out in your enterprise. Sorry for the long delay in getting this posted. I hope to do better in the future.

Ten Hard Questions About Security: Question 1

harperse — Tue, 08 Aug 2017 13:32:55 GMT

Question 1: Who should I trust?

This question should be in the back of your mind for every solution you are designing or consulting on, every answer you give to every question you are asked about security, and every decision you make in regards to enterprise security. Information security spending is nearing $100 billion yearly across the globe, and everyone and anyone with an IDE and a couple of programming classes under their belt thinks they can produce a security solution that is "ground breaking" or "turnkey" or "industry leading" or "complete, holistic end-to-end". Most of these claims may be true for their own business, as most of these products are simply a small piece of niche security on top of a myriad of already existing solutions which you are probably already utilizing. Don't be wowed by their flashy advertisements, cheesy taglines, or brash statements. There is only one person you should be trusting to make decisions for your enterprise: yourself. Now, don't let your head get too big. That wasn't a compliment, it was a caveat. If you want to be trusted within your enterprise, you have to give reasons why you should be trusted. Title alone does not dictate good decision making. It simply means that someone trusted you to have the final say in their enterprise's security. While we are not giving compliments, let me not give you another one: You are not infallible. You are human. Humans make mistakes. Computers make mistakes too, but the difference is that a computer only does it what a human tells it to do. Whether the computer's error is poor code, incorrect configuration, or the all-too-common using a non-security product as a security product, all of the inherent issues with a computer system ultimately come back to an error or decision by a human.

How can I take the human element out of security?

You can't. While security systems can be great at detecting well-known security threats, and even unknown security threats, a human has to be the driving force saying "yes, this is a threat" or "no, this is not a threat". Sometimes those humans belong to your organization, and sometimes they belong to a vendor from whom you are purchasing services or support. Sometimes they are right, and sometimes they are wrong. The same intelligence refers to fixing software. Sometimes, a bug fix to one piece of code can open holes in other locations. It's not common, but it can happen. Test thoroughly.

Who or what should I let influence me?

There are plenty of "trusted" sources out there. Gartner "magic quadrants" are usually the favorite of C-level decision makers, and anyone else who doesn't do the research themselves. Even though a picture may be worth a thousand words, the magic quadrants don't tell the whole story. The axes on the Gartner version for products in any space, not just security, are usually labeled "Completeness of Vision" and "Ability to Execute". The quadrants usually themselves contain labels like "Challengers", "Niche Players", "Visionaries" and "Leaders". When you really think about those labels, none of them infer anything negative about the products reviewed, not that they really should. They really concentrate on the overall product, not important factors like a specific functionality you may be concerned with, or the ability or likelihood of smooth integration into your environment. Weigh the factors like those closely. Then there's the "untrusted" sources; bloggers, "industry experts", and other people who do perform enterprise security for a living. While their advice may be sound for their particular situation, it does not mean it is right for yours. There is no "one-size-fits-all" solutions in the world of security. This applies to both physical and logical security. While one company may brag about how secure their enterprise data centers may be, if you are in a co-location situation, this doesn't affect you. Likewise, if co-location providers list the merits of hosting your infrastructure with them because they are so secure, and your enterprise has some legal or contractual requirements to host onsite, their measures may not be sufficient for your enterprise. Then there is the most dangerous category of all: the people who pay the bills. Sometimes, the most expensive solution is the best. You recognize it, your teams recognize it, your administrators and architects recognize it. You go through whatever processes your company may have in place to purchase said solution, but you can all guess what happens next. The people holding the purse strings aren't willing to pay for it. Whose fault is it? No one's really. Most financial people in the business world are not IT focused. Conversely, IT people can tend to want to overspend on solutions just because they are the newest, shiniest piece of technology out there. We are probably all somewhat guilty of it, whether in our personal lives or at work. The allure can be hard to resist. If you really believe that a piece of technology is the best for your needs, be prepared to defend your situation in terms of money. Think of the value of the assets being protected, both physical and intellectual. That's the scariest number.

Trust, but verify!

Advice is great, but we've all gotten bad advice at one time or another, whether it be personal or professional. The heading says it all. Fact/source/data-driven analysis of any complex problem will lead you to a more rational solution. I don't infer fact, source, and data interchangeably there. They are 3 separate and distinct drivers in your decision. Data is no good if you don't know the source from which it came. And if the source from which the data comes is not basing the data from factual information, it's as good as garbage. Let the data do the work for you. It may not always be the answer you were looking for, but it's an answer. Don't allow your personal feelings to cloud the decision. Got a suggestion for more content? Feel free to leave a comment below. The questions are meant to be "living documents", allowing for reference over time.

Ten Hard Questions About Security: Introduction

harperse — Tue, 01 Aug 2017 13:58:41 GMT

If you have been in the security field for any amount of time, you have most likely heard of the "10 Immutable Laws of Security Administration" ( https://kktechkaizen.blogspot.com/2010/02/how-to-think-like-hacker-scott-culps-10.html) published by Scott Culp of Microsoft back in the year 2000, or the collective update published by the Microsoft Security Research Center (MSRC) known colloquially as version 2.0 (https://technet.microsoft.com/en-us/library/hh278941.aspx) sometime after. If you have NOT heard of these laws, and your job title contains the word "security", start clicking those links above and get your printer whirring. They should be somewhere visible on your workspace at all times. Despite their age, they have held up quite well over time. The original 10 dealt with protection and prevention, or staying ahead of the "bad guys". It always seemed very reactive to me, and rightly so. The field of information security was still in its infancy as an industry. The majority of people employed in 2000 in information security worked for anti-virus vendors, as the virus was seen as the force majeure for exploiting security flaws, either in products or in computing environments. The second version dealt with guidance and preparation, or placing you on the defense and preparing your systems for an attack. In moving from a reactive to a proactive stance, the second set accomplishes far more than the first from a preparedness standpoint. However, it still seems to me that this set addresses security as an afterthought and not a design decision. I will only say this once, but I'm going to say it in all caps: SECURITY SHOULD NOT BE AN AFTERTHOUGHT! Do I have your attention now? Even if your eyes immediately caught the all caps and kept reading from there, good. You'll have time later to go back and review the laws after you've asked yourself these questions, but we will get to that in a moment. Here's some questions I'm sure some people may have, just on the title:

Why are they questions?
- They are questions because someone already wrote laws, and I wanted to be different. :) Seriously though, some people don't respond as well to statements as they do to questions.
- If you ask a child a question such as "Did you clean your room?", you will usually get one of three answers: Yes, No, or . With a positive response, you can elicit praise and move on. With a negative response, you get the chance to ask another question, such as "Why not?" or even "Could you go do that now?". Even with an excuse, you get the chance to ask follow-up questions pertinent to the excuse and it's bearing on their ability to complete the task.
- If you address a child with a statement such as "Clean your room.", the response from most children will probably not be entirely positive. Typical responses may include crying, stomping, screaming, running away, or falling on the ground and acting unable to move. The children will have some responses, as well.
Why are they hard questions?
- The hardest questions are the ones to which we don't want to hear the answers. The questions which make us doubt ourselves, our work, our previous decisions, and our expertise.
Why are there only ten questions?
- There aren't only ten questions. Each question is meant to invoke more questions. Conceivably, each question could invoke ten more questions, with each of those invoking more questions (I think you see where I'm going with this...). This set of ten is merely meant as a starting point to start a conversation within your team, organization, or company. I've also included some follow-up questions to start the conversations.
Why didn't you call them "immutable" like the laws?
- Because no question can be immutable. Questions are inherently subjective. If we hearken back to the "Did you clean your room?" question, every parent and every child have a different definition of "clean". The questions are inherently vague; there are no "yes or no" style questions, or even multiple choice questions. Think of the answer to each question like a short essay, potentially containing more questions. Quite philosophical, I know.
Is there a test at the end?
- Yes. The test is to see if your thoughts about enterprise security have changed. To see if your perceptions of solution design have changed. To see if your mindset around implementing security from the start is really about doing what is secure instead of what is easy.

Now then, on to the questions. I'm going to follow each of these up with their own longer entry. But before we see the list of questions, I just wanted to say this: This is not by any means an authoritative list. I am providing these as food for thought for security professionals, IT administrators, CIO/CISO, and basically anyone involved with enterprise-level security matters. Also, there is no order to the questions. Each is meant to function independently, although the follow-up questions (or answers, if you think you have them) may apply multiple times, and there may be some cross-referencing. OK, now on to the questions. Really. I mean it this time.

Who should I trust?
Whose system is this?
What would a highly publicized security breach cost me?
Quis custodes custodiet?
How will this change affect enterprise security?
Is this an industry best practice?
Is time being spent recreating products or functionality that are already generally available on the open market?
How old is that product/appliance/hardware/system?
Whose idea was this?
Technology is not a panacea?

Chew on these for a while. I'll be back every week or so with a post about each question. If you choose to post a comment below, please keep it civil. This is not a finger-pointing exercise. It is an exercise in questioning the "status quo" in IT security, and in developing IT security talent. One last thing: The title of the series says 10 questions. Really, there will be about 15 posts on this subject. I can count, I just chose the title because "10 hard questions" sounds better than "15 vaguely interrelated posts". Happy questioning!

Welcome!

harperse — Fri, 07 Jul 2017 09:57:15 GMT

Hello readers, and welcome to new blog, Peanut Butter Security. Ok, stop. First question: Why Peanut Butter Security? Well, the answer is pretty simple...I like peanut butter. In fact, I really like peanut butter. But the concept of peanut butter is very simple; you take peanuts and smash them into a paste, and apply the paste to the starchy object of your choosing. Some folks cook with it, as is popular in many Asian cultures. Some people eat it with a spoon right out of a jar (no judgment here). Some terribly unlucky people are allergic to it, as well (peanut oil, technically). But everyone knows one thing about peanut butter: PEANUT BUTTER STICKS! And that's the concept I'm trying to deliver here, security and technical points that stick. So go forth and read on. Even if you are allergic to peanut butter, I can promise you that you will survive this blog, and hopefully learn a few things along the way. Sean Harper Premier Field Engineer #proudmicrosoftemployee