I delivered this presentation at the University of the Incarnate Word in San Antonio, Texas, to a group of students studying information security. They're learning plenty about the technical aspects of information security, but I wanted to talk to them about the non-technical aspects as well. This presentation is meant to be a low-tech, more social introduction on how to handle security within a large organization.

1. Major Hayden
University of the Incarnate Word - November 2, 2015
Five lessons I learned
about information security

2. A bit about me

3. Major Hayden
Principal Architect at Rackspace
Fedora Security Team
Package maintainer
Fedora Planet blogger
Former board member
Ambassador
Ansible
Python
OpenStack
Xen/KVM/Containers
Information Security

4. Major Hayden
Principal Architect at Rackspace
GIAC Certified Unix Security Administrator
Paper: Securing Linux Containers
http://bit.ly/securinglinuxcontainers
GIAC Security Essentials Certification
Red Hat Certified Architect

7. icanhazip.com
icanhazptr.com
icanhaztrace.com
icanhazproxy.com
icanhazepoch.com
icanhaztraceroute.com

8. Agenda
How did I get into
information security?
Five lessons learned
(many of them learned the hard way)
Final thoughts
(and some required reading)

9. How did I get into
information security?

10. How did I stumble into
information security?

11. I sent an angry email
after a security incident.
Special note: this is not a recommended method
for getting into an information security career.

12. Impromptu calendar invitation from
the Chief Security Officer (CSO) arrives

13. “I’m totally fired.”

15. Lesson 1:
Information security requires
lots of communication and relationships

16. People within businesses generally
fall into one of three security mindsets:

17. “Security is mission-critical for us
and it’s how we maintain
our customers’ trust.”
These are your allies.
Share your intelligence with them frequently.
They must be ”read into” what’s happening.
Highlight their accomplishments and efforts
to your leadership and theirs
at every possible opportunity.

18. “Security is really important,
but we have lots of features to release.
We will get to it.”
These people see security as a bolt-on,
value-added product feature.
Share methods for building in security from the start.
Make it easier for this group to build secure systems
through technical standards.

19. “I opened this weird file from
someone I didn’t know
and now my computer is acting funny.”
This group is your biggest risk.
Take steps to prevent them from being able
to make mistakes in the first place.
Regularly send high-level communication
to this group with useful information
in a friendly format.

20. Lesson 2:
Spend the majority of your time and money
on detection and response capabilities

21. Make it easier to detect an intruder
and respond to the intrusion
Don’t let your
intruders act like this:
Make them
act more like this:

22. Ensure that if an attacker
gains access to your network,
you know about the intrusion
and how to respond
Automation,
aggregation, alerting
Firewall logs
Netflow
data/analysis
Intrusion Detection
Systems (IDS)
Server logs
Authentication
logs
Physical security
devices
Immediate,
coordinated response

23. Incident communication
Use broad communication that
hints at urgency without sharing details.
Share the details with your allies in the business.

24. Lesson 3:
People, process, and technology
must be in sync

25. After an incident:
Don’t talk about people*.
Don’t talk about what could have been done.
Don’t talk about vendors.
* No matter how delicate you are, you will eventually “call the baby ugly”.

26. Assume the worst will happen again.
Design processes and technologies to
reduce its impact in the future.
This is an iterative process.

27. Lesson 4:
Set standards, not policies.

28. Use a little psychology to
drive the behavior you truly want:
a more secure infrastructure

29. Compare these two methods of
communicating with the business:

30. “If your system doesn’t pass this PCI-DSS audit,
we won’t be able to take credit cards.
We know what that means.”

31. “We have a technical standard
for public-facing environments
that you need to meet,
and we have some tools
to self-assess your systems.”

32. Technical people can easily
digest technical standards, but
not lengthy compliance documents.
Design a standard so that an environment
can meet multiple compliance programs
if it is followed carefully.

33. Lesson 5:
Don’t take security incidents personally.

35. Security incidents highlight
areas for improvement.
They also give you a better idea
of what attackers want from your business.

36. Take the time to do a
thorough root cause analysis.
Adjust spending, priorities, and tasks
based on what you find.

37. Final thoughts

38. Information security thrives on frequent,
honest, meaningful communication
more than anything else.
Security incidents will happen.
How you respond to them is critical.
Design systems that prevent people
from making mistakes in the first place.

39. Switch: How to Change Things
When Change is Hard
Chip & Dan Heath
When you want to make change
happen, this book will help you
focus your thinking. It has some
great frameworks and situational
examples.

40. Winning With People
John Maxwell
Building relationships requires
learning a lot about yourself first.
This book is broken into five
sections that gradually take you
through how to have stronger,
lasting relationships with others.

41. The Phoenix Project
Gene Kim, Kevin Behr, and George Spafford
A must for anyone working in IT.
It’s a modern spin on Goldratt’s
classic, The Goal, that focuses on
a new IT executive that is in over
his head. Security and
compliance issues play a big role
in how he works within his
business.

42. Thank you!
majorhayden
major.hayden@rackspace.com
major.io

43. Image Credits
Bank safe on title slide: By Alvesgaspar (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via
Wikimedia Commons
Honduran TIGRES soldiers: United States Special Operations Command (Flickr: https://flic.kr/p/qweJtn, CC-BY 2.0)
Longhorn cattle: Evelyn Simak [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons
NORAD: By NORAD (government website) [Public domain], via Wikimedia Commons
Iterative process diagram: By Aflafla1 [CC0], via Wikimedia Commons