If you weren’t able to make it, don’t fret! This post will cover some of the main points of the talk and link to the video and slides.
I was recently asked to talk to Computer Information Systems students at the University of the Incarnate Word here in San Antonio about information security in the business world. The students are learning plenty of the technical parts of information security and the complexity that comes from dealing with complicated computer networks. As we all know, it’s the non-technical things that are often the most important in those tough situations.
My talk, “Five lessons I learned about information security”, lasted for about 30 minutes and then I took plenty of technical and non-technical questions from the students. I’ve embedded the slides below and I’ll go through the lessons within the post here.
Lesson 1: Information security requires lots of communication and relationships
Most of what information security professionals do involves talking about security. There are exceptions to this, however. For example, if your role is highly technical in nature and you’re expected to monitor a network or disassemble malware, then you might be spending the majority of your time in front of a screen doing highly technical work.
For the rest of us, we spend a fair amount of time talking about what needs to be secured, why it needs to be secured, and the best way to do it. Information security professionals shouldn’t be alone in this work, though. They must find ways to get the business bought in and involved.
I talked about three general buckets of mindsets that the students might find in an average organization:
“Security is mission critical for us and it’s how we maintain our customers’ trust.”
These are your allies in the business and they must be “read into” what’s happening in the business. Share intelligence with them regularly and highlight their accomplishments to your leadership as well as theirs.
“Security is really important, but we have lots of features to release. We will get to it.”
These people often see security as a bolt-on, value added product feature. Share methods of building in security from the start and make it easier for them to build secure products. Also, this is a great opportunity to create technical standards as opposed to policies (more on that later).
“I opened this weird file from someone I didn’t know and now my computer is acting funny.”
There’s no way to sugar-coat this one: this group is your biggest risk. Take steps to prevent them from making mistakes in the first place and regularly send them high-level security communications. Your goal here is to send them information that is easy to read and keeps security front of mind for them without inundating them with details.
Lesson 2: Spend the majority of your time and money on detection and response capabilities
This is something that my coworker Aaron and I talk about in our presentation called “The New Normal”. Make it easier to detect an intruder and respond to the intrusion. Don’t allow them to quietly sneak through your network undetected. Force them to be a bull in a china shop. If they cross a network segment, make sure there’s an alert for that. Ensure that they have to make a bunch of noise if they wander around in your network.
When something is detected, you need to do two things well: respond to the incident and communicate with the rest of the organization about it.
The response portion requires you to have plenty of information available when it’s time to assess a situation. Ensure that logs and alerts are funneled into centralized systems that can aggregate and report on the events in real time (or close to real time). Take that information and understand where the intruders are, what data is at risk, and how severe the situation really is.
From there, find a way to alert the rest of the organization. The United States Department of Defense uses DEFCON for this. They can communicate the severity of a situation very quickly to thousands of people by using a simple number designation. That number tells everyone what to do, no matter where they are. Everyone has an idea of the gravity of the situation without needing to know a ton of details.
This is also a good opportunity to share limited intelligence with your allies in the business. They may be able to go into battle with you and get additional information that will help the incident response process.
Lesson 3: People, process, and technology must be in sync
Everything revolves around this principle. If your processes and technology are great, but your people never follow the process and work around the technology, you have a problem. Great technology and smart people without process is also a dangerous mix. Just like a three-legged stool, all three legs must be strong to keep it stable. The same goes for any business.
When an incident happens, don’t talk about people, what could have been done, or vendors. Why? Because no matter how delicate you are, you will eventually “call the baby ugly”. Calling the baby ugly means that you insult someone’s work or character without intending to, and then that person withdraws from the process or approaches the situation defensively. That won’t lead to a good outcome and will usually create plenty of animosity.
Assume the worst will happen again and make your processes and technologies better over time. This is an iterative process, so keep in mind that a thousand baby steps will always deliver more value than one giant step.
Lesson 4: Set standards, not policies
Policies are inevitable. We get them from our compliance programs, our governments, and other companies. They’re required, but they’re horribly annoying. Have you ever read through ISO 27002 or NIST 800-53? If you have, you know what I mean. Don’t get me started on PCI-DSS 3.1, either.
What’s my point? Policies are dry. They’re long. They’re often chock-full of requirements that are really difficult to translate into technical changes. There’s no better way to clear out a room of technical people than to say “Let’s talk about PCI-DSS.” (Seriously, try this at least once. It’s amazing.)
You need to use the right kind of psychology to get the results you want. Threatening someone with policy is like getting someone to go in for a root canal. They know they need it, but they know how much it will hurt.
Instead, create technical standards that are actionable and valuable. If you know you need to meet PCI-DSS and ISO 27002 for your business, create a technical standard that allows someone in the business to design systems that meet both compliance programs. Make it actionable and then show them the results of their labor when they’re done.
Also, give them a method for checking their systems against the standard in an automated way. Nobody wants The Spanish Inquisition showing up at the end of a project to say “Hey, you missed something!”. They’ll be able to check their progress along the way.
Lesson 5: Don’t take security incidents personally
This one is still a challenge for me. Security incidents will happen. They certainly won’t be fun. However, when the smoke clears, look at the positive aspects of the incident. These situations highlight two critical things:
- Room for improvement (and perhaps additional spending)
- What attackers really want from your business
Take the time to understand what type of attacker you just dealt with and what their target really was. If a casual script kiddie found a weakness, you obviously need to invest in more security basics, like network segmentation and hardening standards. If a nation state or some other type of determined attacker found a weakness, you need to understand what they were trying to get. This can be challenging and sometimes third parties can help give an unbiased view.
There are three really helpful books I mentioned in the presentation:
These three books help you figure out how to make change, build relationships, and work around challenges in IT.
If you haven’t been to your local university to meet the next generation of professionals, please take the time to do so. There’s nothing more exciting than talking with people who have plenty of knowledge and are ready to embrace something new. In addition, they yearn to talk to people who have more experience in the real world.
Thanks to John Champion from UIW for asking me to do a talk! It was a fun experience and I can’t wait to do the next one.
I’ve had a great time talking to people about my “Be an inspiration, not an impostor” talk that I delivered in August. I spoke to audiences at Fedora Flock 2015, Texas Linux Fest, and at Rackspace. The biggest lesson I learned is that delivering talks is exhausting!
Frequently Asked Questions
Someone asked a good one at Fedora Flock:
How do you deal with situations where you are an impostor for a reason you can’t change? For example, if you’re the only woman in a male group or you’re the youngest person in a mostly older group?
I touched on this a bit in the presentation, but it’s a great question. This is one of those times where you have to persevere and overcome the things you can’t change by improving in all of the areas where you can change.
For example, if you’re the youngest in the group, find ways to relate to the older group. Find out what they value and what they don’t. If they prefer communication in person over electronic methods, change your communication style and medium. However, you shouldn’t have to change your complete identity just for the rest of the group. Just make an adjustment so that you get the right response.
Also, impostor syndrome isn’t restricted to a particular gender or age group. I’ve seen it in both men and women in equal amounts, and I’ve even seen it in people with 40 years of deep experience. It affects us all from time to time, and we need structured frameworks (like OODA) to fight it.
How do I battle impostor syndrome without becoming cocky and overconfident?
The opposite of impostor syndrome, often called the Dunning-Kruger Effect, is just as dangerous. Go back the observe and orient steps of the OODA loop (see the slides toward the end of the presentation) to be sure that you’re getting good feedback from your peers and leaders. Back up your assertions with facts and solid reasoning to avoid cognitive bias. Bounce those ideas and assertions off the people you trust.
When I make an assertion or try to get someone else to change what they’re doing, I’ll often end with “Am I off-base here?” or “Let me know if I’m on the right track” to give others an opportunity to provide criticism. The added benefit is that these phrases could drag someone with impostor syndrome out of the shadows and into the discussion.
That leads into another good question I received:
How can we reduce impostor syndrome in open source communities as a whole?
The key here is to find ways to get people involved, and then get them more involved over time. If someone is interested in participating but they aren’t sure how to start, come up with ways they can get involved in less-formal ways. This could be through bug triaging, fixing simple bugs, writing documentation, or simply joining some IRC meetings. I’ve seen several communities go through a process of tagging bugs with “easy” tags so that beginners can try to fix them.
Another more direct option is to call upon people to do certain things in the community and assign them a mentor to help them do it. If someone isn’t talking during an IRC meeting or piping up on a mailing list, call them out — gently. It could be something as simple as: “Hey, [name], we know you’re knowledgeable in [topic]. Do you think this is a good idea?” Do that a few times and you’ll find their confidence to participate will rise quickly.
Insides vs. outsides
Someone stopped me outside the talk room at Texas Linux Fest and said a leader at his church summarized impostor syndrome as “comparing your insides to someone else’s outsides”. That led me to do some thinking.
Each and every one of us has strengths and weaknesses. I’d wager that we all have at least once vice (I have plenty), and there are things about ourselves that we don’t like. Everyone has insecurities about something in their life, whether it’s personal or professional. These are things we can’t see from looking at someone on the outside. We’re taking our laundry list of issues and comparing it to something we think is close to perfection.
Don’t do that. It’s on my last slide in the presentation.
You know at least one thing someone else wants to know
After doing the talk at Rackspace, I was pulled into quite a few hallway conversations and I received feedback about my presentation. In addition, many people talked about their desire to get up and do a talk, too. What I heard most often was: “I want to do a talk, but I don’t know what to talk about.”
It reminds me of a post I wrote about writing technical blogs. There is at least one thing you know that someone else wants to know. You might be surprised that the most hit post on my blog is an old one about deleting an iptables rule. Deleting an iptables rule is an extremely basic step in system administration but it’s tough to remember how to do it if you don’t use the iptables syntax regularly.
Rackspace holds Tech Talk Tuesdays during lunch at our headquarters in San Antonio each week. It’s open to Rackers and escorted guests only for now, but our topic list is wide open. Rackers have talked about highly technical topics and they’ve also talked about how to brew beer. I’ve encouraged my coworkers to think about something within their domain of expertise and deliver a talk on that topic.
Talk about your qualifications and experience without bragging
You can be humble and talk about your strengths at the same time. They aren’t mutually exclusive. It can be a challenge to bring these things up during social settings, especially job interviews. My strategy is to weave these aspects about myself into a story. Humans love stories.
As an example, if you’re asked about your experience with Linux, tell a short story about a troubleshooting issue from your past and how you solved it. If you’re asked about your python development experience, talk about a project you created or a hard problem you solved in someone else’s project. Through the story, talk about your thought process when you were solving the problem. Try your best to keep it brief. These stories will keep the other people in the room interested and it won’t come off as bragging.
Thanks to all of the people who attended my “Be an inspiration, not an impostor” talk at Texas Linux Fest 2015. Some A/V issues caused my time slot to get squeezed and the audience had to put up with the “ludicrous speed” version of the presentation.
The slides are a little different from the slides at Fedora Flock, but they’re mainly the same:
If you’d like to review the slides, they’re on SlideShare:
Quite a few people came up after the talk and throughout the day to share some of their stories and challenges. It was extremely rewarding to have those conversations and share solutions.
I’ll be doing the talk once more at Texas Linux Fest in San Marcos on August 22.