Security Speed Dial
Who do you call when you have a security problem?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Cybersecurity
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Security Voices is the latest podcast that invited me to join them in a security conversation. On this particular podcast, they told me I was the first person on the show that was not from their personal network. It was indirectly the result of a recommendation from someone who read my book, Cybersecurity for Executives in the Age of Cloud. I felt like I was on a show with security legends!
I am always amazed that these podcasts with so many incredible prior guests reach out to me to participate in their shows. When I look at the other people invited to speak, I feel like wow, they are asking me? When I got involved in security, I just wanted to understand how attackers broke into systems and to help people with security. I am happy when something I’ve said or done makes the cyber world a little bit safer. I am so honored to participate in the conversation.
Who do you call with security problems?
One of the questions they asked me made me think. Who is on your security speed dial? I had to ponder the question. Well, honestly, no one specifically. I considered why that is and how I learn about security. I occasionally call friends who work in security, but those calls are often personal in nature, not to get security advice. I talk to non-security friends more frequently, to be honest. Sometimes they ask me when they have security questions. I also answer phone calls on security questions for a living through IANS, ironically.
Why don’t I have people on my speed-dial that I call when I have security questions? Perhaps it had something to do with growing up in a small town where no one was around to ask for help with anything when I learned to program at age 12 on a TI-99/4a. I wasn’t allowed to use the modem, and no one around me was interested in or had any clue what I was doing.
Maybe it’s just how I am. Steve Wozniak, the co-founder of Apple Computers, writes in his memoir:
Most inventors and engineers I’ve met are like me — they’re shy, and they live in their heads. They’re almost like artists. In fact, the very best of them are artists. And artists work best alone where they can control an invention’s design without a lot of other people designing it for marketing or some other committee. I don’t believe anything really revolutionary has been invented by committee. If you’re that rare engineer who’s an inventor and also an artist, I’m going to give you some advice that might be hard to take. That advice is: Work alone. You’re going to be best able to design revolutionary products and features if you’re working on your own. Not on a committee. Not on a team.
So how do I solve security problems? Obviously, I don’t know everything or have all the answers without getting help from other people. When I have security questions, I opt to solve them in different ways than the phone-a-friend option. These are the primary ways I figure out how to resolve security issues:
- Research
- Hands-on trial and error
- Go to the source
This methodology may not work for everyone. At times it is probably a slower approach for an immediate problem. It helps me dive deeply into topics and understand them at the core. It also helps me validate answers through cross-reference and personally validating solutions. Here are some examples of how I use these methods to obtain information.
Research
When I want to learn more about a topic, I research it extensively. Initially, I, like most people, did not think the cloud was very secure. I looked into AWS when it first came out not only as an option for hosting servers but because I saw a lot of malicious traffic from their network hitting my own. I researched and found articles and discussions on the topic. Experts said no controls existed to segregate virtual machines on the hypervisor. I was running e-commerce websites and was concerned about seeing logs between those hosts that did not appear to be accessible to me.
Years later, when I saw the CIA was using AWS, I decided to take another look. At this point, I read all the AWS white papers at the time — about 70. Now there are probably too many. The documents convinced me that they had made significant improvements. I continue to research AWS and other cloud platforms to this day extensively and put this information into my cloud security class.
Cloud security is my main areas of focus. That includes application and cloud penetration testing. When I want to learn about new pentesting techniques, I scour the Internet. I look at code in GitHub. I follow security professionals on Twitter. I watch a lot of videos and, prior to February 2020, attended conferences like the last one I spoke at— RSA. I read reports and articles. I review the documentation about how the technologies I’m trying to test work to see if I can find gaps to exploit. Once I figure out how things work, I sometimes come up with new ideas to explore.
When I wrote my book, Cybersecurity for Executives in the Age of Cloud, I knew a lot about security, but I wanted to ensure my statements were factual. As I wrote out my thoughts, I researched online sources to corroborate my statements. That’s why my 350-page book has 40 pages of references. It helped me ensure what I was saying was accurate. Additionally, it allows others who want to dive deeper into a particular aspect of security to find more information on the topic.
When I write research reports for the IANS customer portal, I generally have an idea about what I want to write. However, I do not solely write based on the thoughts in my head. I review documents and data for the latest developments. I often also out tools or write code, which is the topic of the next section.
Hands-on trial and error — just do it!
Any time I can, I test out the technology to see how it works and sometimes, how we could make it better. I have had many interesting discoveries while diving into network packets. I have been able to prove my crazy ideas will sometimes work by getting in and implementing things. The main things that hold me back are the time and money to research all the new ideas in my brain.
When I heard about e-commerce, I believed it was the future. A lot of people were skeptical at the time. I immediately switched jobs to work at a small company so I could learn web programming. I remember one of my co-workers telling me that it was a risky move. The thought never occurred to me.
When that company I worked for was not actually doing e-commerce projects, I started my own side business. I offered e-commerce services and figured it out. Ironically, my employer later asked me to work on-site at a client as their “e-commerce expert.” They had no one else doing e-commerce at the time. That led to an acquisition of my employer by the customer.
When one of my customers wanted to add SEO (search engine optimization) to her website, I was annoyed that she paid some “experts” a lot of money for something I was sure I could figure out. As it turned out, they were creating about five hard-coded web pages for a site that had over 1500 products. I took what I learned from them and through reverse-engineering the search engine algorithms and built SEO into the core of her content management platform, something no one else was doing at the time. Her search engine rankings and sales skyrocketed. Her business grew to a multi-million dollar company.
After reading all the AWS white papers, they convinced me of the benefits the cloud had to offer. Sure there were gaps, but it couldn’t be worse than what I saw on deployment night. I was convinced of the security benefits automated deployments and the segregation the cloud had to offer. Inter-host communication seemed pretty solid. You could create granular network rules for each application and host, something now called “zero-trust.” My employer, at the time, was not so convinced.
To learn this new technology, I started moving the remnants of my previous company to AWS, the one I would not move earlier due to security concerns. I slogged through the tutorials and got hands-on with the services and technology. The words were strange and foreign, but over time, I became familiar with it and figured it out. I started the Seattle AWS Architects and Engineers Meetup to learn from others using AWS. Later, Capital One invited me to be on the original cloud team.
I chose to write new code (torture myself?) when I wrote my last two research papers for my master’s degree in information security engineering to show how my ideas could work. In both cases, I had to ask for an extension because I ran out of time. I was writing about things no one I knew was doing or anyone had published. I hit numerous bumps in the road. Writing code for something new when there’s nothing to copy can be time-consuming! Those papers generally took 3–4 months.
One paper was about event-driven security and automated intrusion detection and response in the cloud (which I asked vendors about who sponsored and spoke at our meetup, and none of them were doing). Now everyone talks about automated incident handling, and there’s even a new acronym for it, SOAR (because everything must have an acronym). That stands for Security Orchestration, Automation, and Response. Gartner is already promoting the term, but a page on the topic does not yet exist on Wikipedia. I’m sure it will get updated any minute now. Back then, there were no examples of such automation for incident handling and no acronyms for this concept.
The last paper I wrote was on Packet Capture in AWS, after someone told me it was impossible. I already knew it was, but I had to prove it. Although we were not doing it at Capital One, I had been thinking a lot about how to structure the networks to facilitate it and had asked network experts at AWS if anyone else was. Yes. I frequently used tcpdump to capture packets on AWS hosts when troubleshooting network issues. Obviously you could capture packets. You just might have to do it a bit differently.
Completing the last paper’s code was quite challenging because while I was trying to finish the project, the product I was working with had limitations and very little documentation. No one ever attempted to automate the deployment completely or used the device the way I was trying to use it. Additionally, AWS S3 kept failing to upload my files periodically. I contacted support but could not get it resolved because the problem was sporadic. I resorted to posting on Twitter each time S3 failed until the EC2 team invited me to come in and talk to them about what I was trying to do. Before that happened, they figured it out — and yes, it’s always DNS.
Sometimes, there is no one to ask. You just have to go figure it out!
Go to the source
I have had a lot of technical and security influences over the years. Sometimes I took classes from them so in order to obtain information from them. Sometimes I sought them out to ask questions. Whenever trying to learn about a new topic, I try to get as close to the source as possible. I want to get to the person or people who are most in-the-know about a the topic.
When I wanted to learn more about startup investments, I went to work for venture capitalists doing technical due diligence. The best way to learn would be to get involved. That was, again, a risky move, as I learned later. I had no idea what I was doing. I just wanted to learn things. I also ended up providing due diligence to a woman’s angel investment group in Seattle that no longer exists. I got to see a lot of new technology and learned how VCs evaluate new businesses. That was pretty cool.
When I wrote my first security white paper on the Target Breach, I figured I should talk to someone working in security for a retail organization. I got in touch with a security person at Nordstrom through a friend. He clearly had security expertise in retail systems. He also happened to have some information from the FBI that was not public knowledge. He provided a link to a case study on Target’s use of a particular auto-deployment technology that Microsoft had recently removed from its website.
When I didn’t know what a point of sale (POS) machine looked like, I asked my friend who owns a restaurant if I could come to take a look at his. It was basically a Windows machine where he also checked email and surfed the web occasionally — not recommended!
When a SANS instructor told me the memory should be encrypted and used some term I wasn’t aware of and said something about an HSM (hardware security module), I got in touch with someone who worked at Thales, a company that makes those devices. That person had never heard the term either, but he had resources to explain how the credit card data could be protected, which I incorporated into my paper.
Often, I learned about and from technical and security experts from afar. One such expert wrote the Jetty web server I used to host e-commerce websites. I thought this embedded webserver was amazing. I admired the code. It had only the things I needed in it. I stripped out anything extraneous, especially after my first data breach. I customized it to build my web application firewall (WAF) though that term didn’t exist then. It was written in my language of choice back in the day — Java. Times have changed.
At one point, I was trying to get load balancing working on my open source Jetty web server for a high volume website. I tried everything I could think of to fix it and read may newsgroup emails. Finally, I convinced the business owner for whom I built and managed the website to hire the person who wrote Jetty, Greg Wilkins. If anyone could solve this person, the person who wrote the software could. He was from Australia, and I believe living in Italy at the point I hired him.
I was pretty sure I was doing everything right when configuring the load balancer, but I couldn’t get it to work. To get help, I went straight to the source — the ultimate expert. Greg took a look at it, and after a short while, he came back and admitted that Jetty had a bug in its load balancer. He agreed to give me some additional support for free, which I used liberally until I finally wore out my welcome. He called it a “statute of limitations.” But hey, he was the best person to ask and got me the fastest correct answers about Jetty!
Although I don’t have a list of people on speed dial that I call with security questions, asking the best expert I can find on a specific topic has always been one of my approaches to get answers to questions. I am fortunate enough to be part of the security faculty at IANS. People call me with questions about the security topics I specialize in — primarily anything to do with cloud security and the applications hosted on those platforms. That’s one of the benefits for IANS customers. You can talk to people who specialize in different aspects of security.
Our differences make the world go ‘round
Different people solve problems in different ways. Whether you ask someone you know in security or figure it out yourself, the critical part is the end result. Does it work? Did it solve the problem? Is it better than the alternatives? Does it fit your current scenario and requirements? That is what is most important! There is not a single way to solve problems in most cases. Additionally, there is often more than one plausible solution, and the same solution is not right in every circumstance.
Often when people call me, they want a “reference architecture” for the cloud. Although some exist, there is no single architecture to solve every problem. Even the latest documents from NIST and CISA on cloud security talk about concepts rather than providing a blueprint for what you should build. Sometimes, what everyone else is doing may not be working. Even if it is, there may be a better solution that will cost less, be more secure, or work better for your use case. I like to take all the information I can obtain as inputs and analyze the problem. I may recommend a standard approach or something new if a situation warrants it.
I am often not satisfied with the status quo. If I see things are not working, that drives me to want to fix problems. Sometimes my ideas are out of alignment when the mainstream thinking of the moment, like when I wanted to create outbound firewall rules after my first data breach, and my hosting company told me no one else does that. Now most security-aware people do. I base my solutions on research and in-depth analysis of the issues that drive the problem, not what everyone else is doing. The freedom to explore and find the best solution with no restrictions or limitations is one of the reasons I love running my own company — 2nd Sight Lab.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2020
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
