Security Architecture Tips of The Week #1
Earlier this week I was challenged by my SecDevOpsAI partner in crime Chris Cochran to share 100 tips that I’ve learned as a Security Architect. I plan to share all 100 tips in articles, videos, and podcast episodes — Each week I’ll share 7 tips in a complete article. My goal is to deliver Security Architecture best practices and share many of the lessons that I’ve learned over time.
Security Architecture Tip 1/100 — What is Security Architecture?
There are many definitions of this term — Wikipedia’s definition of architecture works great with some tweaking — “planning, designing, and constructing ̶b̶u̶i̶l̶d̶i̶n̶g̶s̶ Security Controls or any other ̶s̶t̶r̶u̶c̶t̶u̶r̶e̶s̶ Security Policy, Standard, or Guideline”. With that said, the responsibilities of a Security Architect can be quite vast. In my role as a Security Architect, I spend a large amount of my planning, designing and engineering automated workflows for Incident Response and Threat Hunting. This has required me to become an expert in SIEM, Endpoint Detection and Response (EDR), Case Management, Threat Intelligence, and collaborative analyst workspaces (ChatOps). This is not an exhaustive list of domains — in fact, this list keeps growing as analysts and engineers learn new ways to respond to security related events.
Security Architecture Tip 2/100 — Planning
This tip is almost too simple to be covered but after working with dozens of organizations and production environments that can’t afford to be brought down — I’ve experienced more than a few in-progress security related projects without a well-thought-out plan. Agile methodologies and other project management strategies are in demand due to their ability to balance supply and demand of project needs. When technology and human resources are limited I do follow a general set of focus areas to create a project plan.
𝐂𝐫𝐞𝐚𝐭𝐢𝐧𝐠 𝐚 𝐂𝐚𝐭𝐜𝐡 𝐀𝐥𝐥 𝐏𝐫𝐨𝐣𝐞𝐜𝐭 𝐏𝐥𝐚𝐧
Finding examples for Security related project plans on Google can be a great start but often comes with confusion and decision fatigue. The amount of planning required often depends on the size of the project. Today, comprehensive security project plan checklists don’t exist (If there is one that exists please let me know and I’ll paste it here!). While operating in my domains of expertise these are always focus areas I include when creating a project plan for a security control.
- Teammates
- Infrastructure Requirements
- Use Cases (Examples of what the project will accomplish/solve)
- Milestones (Measurement)
- Validation
- Optimization
Security Architecture Tip 3/100 — Create Access for Security Controls
Access is always key when implementing a new security control and any other technology. When working in sensitive or air-gapped networks it’s best practice to document any application or service that needs to reach out to the Internet. It’s not uncommon to forget to open firewall rules / create proxy exceptions for traffic that should reach out to the Internet. When traffic to/from a Security Control is being blocked for unwanted reasons it could impede the effectiveness of an Incident Response team (Especially if that security control needs data from an API). If suddenly find out that my security control is unable to reach necessary resources I typically start with a few common questions and Linux commands if needed:
Is the security control running? How long has the service been running?
systemctl statusAre any errors in application log?
less /var/log/*.logWow, things with this application/service are looking bad! How do find out more details?
journalctl -u <service_name>Have I reviewed network connections?
netstat -peanut These few questions can work as a great starting point
Security Architecture Tip 4/100 — Scripting/Programming
Hopefully as a Security Architect you aren’t tied to completing 100% of the engineering for your security projects. For the majority of my deployments, I find myself working with organizations to implement some custom code. This could be to facilitate the interaction between several tools or a requirement to format and present data in a specific way. After working with dozens of organizations, my bet for scripting/programming is Python and Golang. I’d highly recommend both of these languages because of the ease of use and industry demand (talent in these areas also demand excellent compensation). From a security architecture perspective, here are areas of scripting/programming that I’d recommend being proficient in:
- Formatting Strings (Splitting, Stripping, Appending)
- Parsing JSON objects
- Performing HTTP Requests (GET, POST, etc..)
Creating re-usable functions Need More? Here are a few technologies and Libraries that I’ve been researching/implementing:
- Docker SDK
- Serverless Framework
- Homomorphic encryption libraries
Also, here’s my current open-source project Threat Intel Slack Bot: https://github.com/secdevopsai/Threat-Intel-Slack-Bot
Security Architecture Tip 5/100 — Accessing Devices and Applications
As organizations evolve, technology and infrastructure evolve. To keep my head on straight when starting and providing on-going support to a security deployment I make cheatsheets for accessing my necessary resources. Hopefully, we all have an understanding on how to establish an SSH session with a VM or physical server but what about containers and cloud functions? Today, I spend most of my time with VMs and containers
ssh -i <key> MyDevice(dot)com docker run -it <container_name> bash docker exec -it <container_name> bash • serverless invoke -f <function_name>
Lately, I’ve been doubling down and growing my expertise in cloud functions. Serverless framework, Firebase, and AWS Amplify.
Security Architecture Tip 6/100 — Open source tools
Practicing my craft for the past ten years, I’ve witnessed the explosion of open source libraries and applications. To know which tools you can use for FREE can save a lot of time… And more importantly MONEY 🤑. There are many great resources and so little time to review. Here are a few strategies I take to mastering open source tools:
Discovery
- Search Github for topics of interest (I love awesome-lists on Github)
- Conference Agendas
- Google filters (site:<WhereToSearch(dot)com> search term)
Achieving A Deeper Understanding
- Conference Videos
- Github Readme and ReadTheDocs pages
Maintenance
- News Feeds (Reddit, Medium, Archive)
- Google Alerts
- Conferences
Security Architecture Tip 7/100 — Closed source tools
This tip could be a bit difficult to fully digest because acquiring deep insight of a library, utility, or application could be tough when the code (and other resources) is not available… or even worse, behind a paywall with limited budget. Before joining Demisto (Now a Palo Alto Networks company) I was a user of the free edition and obtained access to the Documentation and Slack channel. By leveraging these few resources I gained a great understanding of the product, release cadence, and team.This could be a great strategy to to evaluate products while increasing your understanding of security technologies. I’ve worked with countless organizations that recruit analysts, engineers, and architects specifically on their ability to work with vendor products. I have a few recommendations for finding the hottest vendors in cybersecurity:
- Crunchbase
- Job Listings and Job Requirements
- Webinars
I’m certain anyone reading this article has been messaged on LinkedIn/Email by a vendor requesting time. I’ve always enjoyed demos — at a minimum I walk away with new ideas and insights as to what others are working on.
