Hudson Bush - Enterprise Security Architecture Isn't Just for Enterprises Anymore

everybody Welcome Hudson [Applause] well thank you everyone for making the poor decision to sit through my talk um some of you may I may be here because you think I'm going to tell a bunch of cool stories about the dragos breach um I can tell a couple but um I want to have a job after this um thank you for anyone that came up before and uh offered you know praise for the blog or anything else about this breach it has been a very fun week for all of us um I do want to sit on my soapbox before I go into Enterprise security architecture with the caveat that talking about architecture and governance in a week

where after where there's a bunch of uh you know cool findings and cool technical things to talk about seems a little out of place but it is what I'm here to talk about I do want to just say that as an industry we obviously have a burnout problem and please you are the only one that can speak up for your own mental health put boundaries between you and your boss or other people at work it is so easy especially in a week of crisis in an incident and anything like this to to burn out to sit at your computer for 18 hours a day and then a couple days this week do something that makes you feel like a

human walk outside go get a meal eat something that isn't a bag of chips you know uh drink something that isn't coffee or Red Bull drink water or something I know it's hard in it you know in crises but I just need to stand on that soapbox I also just want to say any incident responders people who are out there doing this day in day out mad respect a week of this and I never want to do it again um so but again you know thank you everyone for for anyone who said anything positive about that the uh the the event that we had this week so my talk Enterprise security architecture is not just for Enterprises I do have some

caveats here um I know a lot of times we use the word architecture to talk about um design documents we talk you know this is my architecture diagram that is definitely a piece of architecture but I'm talking about Enterprise security architecture I'm talking about governance I'm talking about systems and systems of systems the way that systems interconnect um that does not mean that the common usage of the word architecture does not have a place in what I'm talking about here um there still is I'm still going to talk about all that how to use this design documentation make it our actionable but my experience comes from years of working at small companies uh usually small military manufacturing

companies that have uh small resources so that's why I'm I'm talking about how we can take these Concepts that are usually only for huge organizations and how they can apply to smaller teams um especially a team like dragos now um with that you need to give some caveats um that no I'm not speaking on behalf of the company um obviously um but yeah Hudson uh I work at Drago since I've said a couple times a couple you all have noticed from my shirt and uh I drove up here from Chattanooga to your y'all's lovely town so what is enterprise architecture or Enterprise security architecture there's a lot of definitions the way I boil it down to is it's the Integrations and

relationships between people systems and processes it comes out of a lot of Concepts in the 80s of um how to digi digitize systems and and all of that how to integrate technology and security into business processes where a little past that is a it as a organization or rather as an industry but I still think a lot of these Concepts although they're can't see my slides how long have you not been able to see my slides oh [Applause] well I'll rush through those first ones pretty quickly then um I kind of covered this architecture is governance if architect if governance equals you you might be in the wrong room I've given this talk before where

someone stood up halfway through and went I'm sorry what the hell are you talking about um yeah I thought you were going to show me cool ways to make pretty diagrams nope um I could I do make pretty diagrams but that is not what this talk is about um cool little Powershell looking thing um yeah not speaking on behalf of the company principal security engineer dragos and here is where I was so um I like to think of Enterprise security architecture is the why you know we we have policies and standards that Define what we're going to do resource plans to find who's going to do it projects plans Define when it's going to be done there's work

instructions that say how but architecture kind of defines that y level the foreign why are we making these design decisions why do these things integrate in this way why do we accept this risk and not this you know um obviously not all y's can be defined but it kind of gives you the overarching like meta model for how things work uh this printing diagram in the top right you can't see it but it's just an example of one of these Enterprise architectures from oesa I will be talking quite a bit about not all because I think there's some stupid amount of Enterprise security architectures out there but I will be going through a lot of the big ones and

essentially how we have at this organization in the previous organizations how we've taken that uh these very complicated things and distilled them into something that works I don't know if any of you are sadists or masochists enough to have read through togaf or sabza through uh I think the sabs of Blue Book is 480 pages together orange is like 300 and something gross I like reading those boring things I read nist documents most of you don't so I'm distilling all of my nerdy governancy stuff down so you guys don't have to do it um now kind of covered this as I was ranting but why would we tailor a security architecture uh most of these

architecture Frameworks are old models that haven't necessarily aged well a lot of them are from the 80s um I think togaf might have even started in the late 70s I don't I'm not a historian I don't know them precisely but these are also designed from the business perspective not a technology perspective and the reality is most of the time now the way this works is the the security or the it organization is driving the architecture the business does not care to design a security architecture it still is really good to implement these things because I think a lot of times techies we do not consider the business impacts of what we're doing and that is one of

the cool things about Enterprise security architecture and Enterprise architecture is that it forces you to consider the bigger picture the who who's impacted by things uh and why again why I I covered this but these are huge organizations you will see some of these Enterprise security architectures they are insane they are many pages they are unimplementable and what I have tried to do unfortunately I was really hoping to have public versions of of the documents that we've tailored um but having some hurdles but eventually on my GitHub there will be Enterprise security architecture kind of tailored models um but yeah they're I I've worked at places or worked with places where they have entire organizations uh that are

just architecture you have all these Enterprise security Architects um yeah most of us do not work at a place where that's true because most people do not work at Fortune 50 companies so this caveat here again I'm full of caveats is that uh we are not I do not want to say this is the new dragost Enterprise security architecture that is not what I'm doing we do not need the 15th competing standard uh this is how to take one of these behemoths and tailor things to work for you I've mentioned a few of these um I'm not going to go into all of them I think I go into the first few togaf Oasis zachmanin and then there's a bunch

of proprietary ones almost every government agency has their own um either Enterprise architecture body of knowledge or own Enterprise architecture framework there's dodaf there's there's a bunch of them um I'm interested by this stuff if you want to look at them cool if you do you're probably as much of a nerd as I am togaf the open group architecture framework originated in 95 updated in in 2019 highlighting that to say probably not all that relevant to what we're doing now it is not security focused they although they do have oesa which is the open Enterprise security architecture which was last updated in 2011 so there is some documentation on how to turn togaf into a security architecture but

if you see this diagram um which I don't expect you to be able to see it but it's essentially this is togaf is very focused on how systems are developed and the architecture development framework it's very similar to like a soft a secure systems life cycle secure software development life cycle things like that it's where things plug in and when you consider architecture lots of fun things about content meta models and again I'm just kind of breezing through these to talk about where we've come from uh sabza around that same time in 1995 this one is focused on security architecture as you can see very complicated meta model of layers and different views that you're supposed

to view things from it these get really tricky because you obviously can't see this but there's five different um there's five different views here and at most companies that I've worked at at least there aren't actually these five people you know I have to consider it from this view but there's not that person so again talking about how we can tailor this um very Sab cell is a lot more similar to zachman than it is togaf um it's very risk driven but again fairly out of date the last update was you know seven years ago and uh a little bit has happened to technology in seven years zachman another one of these that shows you a bunch of different views

um again I don't expect you to be able to see this but um IBM so obviously I I highlight the times that these were created and the companies that created them because most of us do not work at an IBM um most of us not work at a place where this where we can Implement something of this scale um yeah 87 updated in 11. it is an ontology and a schema rather than a methodology so it's a way of thinking about things it is not again it is not the how it's the why um again if you like using words like ontology and schema these are things for you to read this that I'm about to show you with the

clouds the CSA TCI reference architecture this is a great example of I I looked at this a hundred times and I haven't even broken down all of what it's saying there's a hundred links in here impossible for any one organization to implement unless you have one team for each of these tiny little boxes um this thing which is the system that the the VA within the government the one VA Enterprise architecture metal model when they were trying to collapse a lot of their disparate technology systems into one uh it's a thousand little architectures in a thousand Little Boxes again uh they had more people working on creating this diagram most likely than have ever worked at any I.T organization

that I've ever worked for um I can guarantee you it probably took 20 people to build this and there's 28t people at Graco so we can't maintain this we can't use this um so what is the good of these things I've made fun of them but I also said that I've read them and I enjoy them um as you can tell I kind of like I I will still make fun of things that I enjoy I like self-deprecating humor but these things they they just don't work for most companies um we can pull the this is the whole thesis of my my talk is that we can pull these good features to some of these

like Legacy architecture Frameworks um for example togaf the architecture development model even even though this is it focused it is really good uh for developing systems it is a plug it plugs their architecture development model into your secure systems life cycle uh development your ssdlc um plug that in look at the deliverables a lot of the deliverables that come in togaf are actually very good and I will get into some of the deliverables that I that I utilize um there's a lot of them where like an architecture Charter most of us are not going to do a project Charter than an architecture Charter we don't have that kind of organization that we we don't want to just create documentation for

the documentation site it's sake but you can look up togaf deliverables you can see them there's actually some really cool stuff um I actually really like the content meta model um and and it I will show you a Content metal model that I've developed that's a lot smaller than tow gas but I like content meta model seems very meta but the reality is it's what types of documents do we have and where do they fit into security or into it or into the entire architecture is it really good to think thing to think about for all of these systems this is the type of documentation this is the the requirements that I have the documentation and the the content that I

require and where they fit in you know what's the difference between a policy What flows into a standard when do you use a Playbook versus a procedure and I will show you the ones that I've created um zachman really good for thinking and putting yourself in someone else's shoes you do need to tailor it because you probably don't have the same viewpoints you don't have those same things but views and viewpoints are really useful for us to get out of that technology box and start thinking okay as the user in in some ways I mean if you're used to like agile and you're used to story user stories it's not that different it's as a business executive I want this system

to do X you know that's one way to think of it but it's in a written in a way that you'd expect something written in the 80 in 1985 to be written um sabza essentially everything I just said about zachman but security um this as much as I love making fun of it the Microsoft zero Crest IAM reference architecture I love this document I use it in my own but this is another example of just how out of touch a lot of these things can be this this is great Microsoft can maintain this they can tell you all the interconnected systems if you are doing IAM through Microsoft you need to look at this and understand

it but the reality is I have never created an architecture document that is anywhere close to that level of system interconnectedness and this is also a great point to point out when I talk about what we usually view as an architecture we we view like a lot of people say I created an architecture diagram what it is is a network map you look at this this is not a network map this is the inter connections of systems when you log in Microsoft InTune checks you against these things well I don't need to walk you through this but again I do want to say as much as I make fun of this this is probably one of the best

architecture diagrams what I just want to call out that I can't maintain it and no one else here can probably you may unless you work at Microsoft then obviously you can because they have here are some architecture Concepts there are a lot more that you could pull out these are the ones that I have tailored and some examples of how I have taken these things and used them um I will say that architecture commonality this is actually one that works really well at some companies um and not as good at some others for example dragos we we're a distributed company we do not have we are not a multinational company who has bought a bunch of small manufacturing

companies if you are this diagram works very well I have worked at places like that if you looked at my LinkedIn and that have that are essentially holding companies that own a bunch of small companies so this is a great way of saying this particular architecture that I'm creating where do is am I expecting this to be consistent against my or entire organization am I expecting everything to be Consolidated you know you you buy a small a small branch in you know in East Tennessee and do you want them to have does this system need to have to to exist there or do we have one centralized in the data center ways of thinking do we want a file server or an

active directory server you know IAM infrastructure at every site things of this this isn't again dragos it accum made a software development company like where I work this something like this does not work but a lot of places I've worked this is actually really useful for defining that level of do I expect every site to have this do I expect you know every site to do this the same or is this some random Erp system that only this site in Southern California has okay well that would be that l in the bottom corner that is a local system that is only that has its own separate architecture it does not I do not expect it to be consistent with all of our Erp

systems I have to say that I'm so glad to be out of an industry where I have to support Erp systems running on Solaris but I'm saying I am not Larry assist admin but I've had to um sorry I haven't yeah trying to get away from too many real life stories uh but I will potentially at the end stakeholder management um this is one of those that um does or doesn't fit into an architecture framework but I think it's really good for and and this is one where I've had to be coach people do not share this do not document this Fleet but it's a good way to rank and come out come up with your communication plans in

your architecture never tell someone never actually Define that this executive is a key player and this one is just to be keep informed you know people might get offended if you're like oh I'm going to give them the minimum effort because they're not worth it they these are things for for more of a mental model of creating these as your communication plans who gets what information um I know again is in project plans and things is techies we a lot of times really like we either under or over communicate but tailoring everything tailor your communication figure out what this executive means what this one doesn't um this is so obviously when you're implementing an architecture framework

like you're implementing anything else um there is a time of transition and that transition probably never ends so these metrics are really good for for that where you are talking about you define what your elements of the architecture are and you define all of those levels are they you know this is essentially like a cmmi or a cmmc level one through five um same with compliance you know marking these and then having remediation plans for all of that um this is where I get into governance nerdiness again uh I will read through most of this so you don't have to but um using viewpoints are actually a really I've talked about it a few times it's very

pedantic to use that word um views or but I but I do think that this is a good thing to kind of understand and to implement it some way there's probably better words for it but again I've read enough of this that it makes sense to me so I use it um a view is a representation of the entire architecture that's meaningful to one or more stakeholders in the system so this is something like this is a slice of this architecture diagram that is relevant to our software developers or to this to our customer service department but and and these are generic and reusable this is essentially not that different from a user story um

now this is interesting in the a view so Viewpoint is the perspective from which a view is taken it's almost like I'm the man behind the camera taking the view so Viewpoint is not something that's documented it's something you you think about what is this Viewpoint um in a Viewpoint Define I'm going to read this because that text is not the yeah so a Viewpoint defines how to construct and use a view the information that should appear in that view and the modeling techniques for expressing and analyzing the information and this rationale for these choices so you may document a way of thinking about this viewpoint but ultimately it's kind of up to the Architects to to take that on so

from this Viewpoint I would expect blah blah blah but it's still and it's very tailored to each individual architecture that is created um these are unique security Architects Concepts that we need to consider because that I don't see in any of these Frameworks and that I've had to include again I really wish that I could have an example of our tailored Frameworks I I am working on those but at some point on my GitHub you'll have them so this will make more sense but you have to consider things like threat modeling um again a lot of you have read the the Drago's breach report from this week I'm going to talk about that a bit threat

modeling is really important in in deciding what controls we put in dragos has actually invested a lot in security tooling and security resourcing but the funny thing is almost none of those tools were even touched or triggered or should have been triggered during the event that happened this week what saved us if in in this again I don't have because we as a company because Rob and Steve and our executives are so transparent I don't have a lot of secrets to share but what I can tell you is that in that report we say the word arbac like 17 times that is because having our back saved our ass um you can't buy a tool you can't spend

I mean sure someone's going to sell you a tool for our back but if you don't have people actually implementing these things and actually deciding does this user need to have this does this user need to have this system should they have this system before they start or do they need to have this training before they have that these things that's threat modeling don't just like this is kind of dated now but I've always liked to talk about Specter and meltdown for threat modeling they were really cool exploits great research but most of us here should not care about Specter and meltdown they don't those speculative execution attacks don't have anything to do with us so it's not

always just chase the newest Vault it's a lot of time it's due the basics sit there and get your data architecture secure look at a draco's breach and tabletop it and and do threat modeling um I could probably I need to stop myself before I turn this entire thing into threat modeling but I do want to just say the word r back a few more times because men that is not a sexy control it is not um I've never heard people giving a talk about doing our our back at scale you know it's not sexy no one cares about it but man the fact that I had to copy and paste into that blog post so many times unable

to access due to rbec unable to act every time I said it I'm just like thank you thank you role-based access control um designed for malice um also relevant to to this you know you you can't just just assume you know everyone using that system is going to use it for for good we are hackers but play that hacker mindset to the near design um I know zero trust is a word that a lot of us don't like the reality is it is a stupid marketing term the words mean nothing but there are Concepts behind zero trust I mean read the I there's a lot of there's a lot of bad takes on it but read the Miss zero trust I think

it's 800 207 really good at making essentially just have Micro segmentation software-defined uh perimeter and do really good IAM that's what it boils down to think about the fence in depth another thing that I think we said seven times in that Vlog um for almost all of your systems you should be defining your CIA goals I know that again CIA confidentiality integrity and availability are somewhat dated we don't want not sexy Concepts in your architecture you do need to Define that I don't know why none of these um architecture Frameworks do but you you need to think about do I care about the confidentiality of the system or the Integrity or the availability which is the most important

it do business impact analysis if I lost the availability of this for this amount of time what um you know what what would be the impact and this is my soapbox usability is security um I actually get scolded fairly often I always have for uh potentially even under securing I I often take the I.T or the user side more than I T or the user do the reality is I work from a perspective of if if you over secure something if you make it difficult to use someone's going to find a way around the security goal a control you do not want to give someone a reason to bypass your control you want to make it easy enough for them to use

that they work within the parameters one of the first time I realized usability is security is I was talking about password resets with with someone at a manufacturing site just some or someone casually mentioned it because over lunch and I hear them someone else goes oh you know I don't worry about the password resets I know it's annoying that we have to change every 90 days back when that was the recommendation do not do that anymore but um then someone goes oh you know what I do I just reset my password 11 times and then it goes back to the old one that is the moment where I realize why you have minimum password H

um always kind of wondered but again designed for malice someone's going to find a way around but also it's the whole reason that that nist 863 revision four is so big on do not require arbitrary password resets because the more difficult you make it for someone you you know and the more you'd make them change their password the more they're going to change and easy to an easy one people are going to use you know spring 2017 is their password because they need something easy to remember if you make it so that they know I'm going to have this password for a year or two they're more likely to keep that password secure they're more

likely to use a long one and not just something silly so usability is security I could give an entire talk on this I also need to stop myself but yeah just think about usability you're you do not make things difficult for your users um there's a large security vendor out there that has very strict rules on file sharing so you know what I've seen the support of this massive password company in password um uh Storage Company use they use their personal onedrives and dropboxes that's what support uses to transfer files because they the company made it difficult for them to share files so now in trying to secure something now they can't even see the files that are being

shared and that's very bad and we'll probably resolve in more fines and ISO violations um so I've talked about a few of these Concepts but style guide um essentially these are the words we use to define the things and and how we talked about systems this is one of the diagrams in here that I'm the most um most proud of I think this really it there's there's more work but this is the content metal model that I'm talking about um it's very simple if you look at the content meta models that a lot of these systems these things have used they're very complicated there's so many different documents but essentially this is the vision and principles of your

security architecture is defined by your architecture framework by your principles and by your roadmap you know what are we going to implement and when you know the requirements come from business requirements so it's mostly boiled down to CIA um you have to mention compliance I've always kind of joked that compliance is the fourth box in CIA the reality is most of the companies that we work for only have security departments because of compliance we have to understand that when we're building requirements we like to think that they care about security I'm lucky to work a company that really does but I've never really seen that before so you have to really fit Factor compliance in and then this next one is

where most people would live is in your policies procedures and your practices um that policies flow and create procedures procedures can pre Play books with work which which work with work instructions things like that Define it for your system but a lot of people don't you know don't use these words precisely these these words policy guideline procedure whatever your organization uses standard you need to understand how they flow in which one informs which which flows back to which um and then in your actual architectures you need system security plans plan of actions and Milestones security risk registers things of that sort again you can probably see my main military manufacturing bent based on some of the

words I'm using Define it for your industry not everyone's going to use the word poem um but I do um I I'm gonna I think I have diagrams for each of these here's some of the content that you want for each of your architectures a charter which I really I know that all of these architecture Frameworks like to think self-importance and they put um they have you do a separate architecture Charter none of us none of the companies we work for care enough about this to do that include your architecture Charter in like your project Charter or your project kickoff however you do it Gap analysis system security plans reference architectures architecture definitions um oh actually I don't go into most of

these um I have a few of them I can share but Target our this is a good way to define your target architect I know those are dark I will go into that um your target architectures when you compare them against your system security plan they sh they that's what you use to develop your plan of action Milestones since this is your Gap analysis look at this is where we're going here's where we are you get your plan of actions and Milestones um now so reference architectures architecture definitions reference architectures are a lot of those things I was showing earlier you know that complicated um Microsoft One reference architecture is anytime you build an identity and access

management system these are the building blocks that an IAM system needs to have or a backup system or whatever it is and then the architecture definition is okay in our active directory um IAM our active directory IDP rather this this is how we conformed with this so it's a much shorter much more specific document but reference architectures are the these are the building blocks essentially I mean in a larger organization reference architecture says if you can build your system within these channels Within These Avenues we you know we will Auto approve it um you know things like architecture review board and all that and then architecture definition is again how you defining how you fit into that

architecture reference uh that reference architecture this and this is another example of how I like to while this does look complicated there's a lot of arrows it's it's also not um you know this is how I like to kind of dumb down or simplify uh architecture Frameworks a little bit uh these architecture diagrams and and this is a pretty simple one for incident detection this is something that all of us obviously do but it's showing where each of your controls and your different systems fit into and flow into different places of the incident life cycle you know detection flows into incident response here's the three and here's how detections flow into that what does threat where does threat

hunting fit in where to threaten tell feeds you know in in understanding because most of these should be similar to a life cycle where something like a debrief in your Lessons Learned should go back into your incident preparation this is the sort of thing you want for most of your systems if you're building a system for incident detection it needs to have this sort of life cycle and apparently I'm talking fast today because I am running a couple minutes early so but I do have my my tldr um in case Enterprise architecture puts you do to sleep for the last 38 minutes um if you weren't paying attention or if you were Enterprise security architecture provides a Common Language

and framework for security implementations um why do we not use the old systems because they're old and they're for organizations that are huge and most of us are working at small companies and all of us are working in the year 2023 so we do not want to use these things that were not made for us um well you do you can pick and choose which piece of these you want to create you want to implement to create a model that works for your organization and I do think it's useful I mean obviously this way of thinking has helped us here at trade us we were able to stop but we were able to stop but

um a couple common questions that come up is I've had a lot of people come up to me and say hey I didn't even know about Enterprise security architecture until a few weeks ago or a few months ago RIT team is building out is using togaf they're finally implementing this how do I fit into it and and so that's just a common one in that you either let them lead it and you look at like oisa which is they're essentially the togaf like not the the add-on you things like that that is an interesting one to think about is how do we kind of fit into I.T and a lot of it is just the words that

I've used here make sure that in any of their architectures that are considering CIA and those few few requirements make sure because you know we like to do things in silos but the whole point of Enterprise security architecture is not doing things in these silos it's trying to get all the systems together and understand how they work so um I do see that slides will be at homebrewtech.com talks except for I cannot figure out the MFA to get onto my my website and change it but I will try that um uh questions for the most part um you know I'd ask you to direct them to uh home to to me on Twitter and I can

answer a lot but um thank you everyone and I'm ending five minutes early it seems like so giving you more time at the bar and to conversate but um thanks everyone for attending this and um I hope you got something out of it thank you [Applause] okay thanks Hudson um yeah I guess uh so I just had a question first off the bat you mentioned that there's uh an MFA issue on your website is that because you're not running it on Solaris oh or what's the oh sick burn from the Solaris guy okay all right does anybody have any actual questions for our speaker put your hands way up okay I see one over there I'm gonna come I'm gonna I'll head

that way pardon me your architecture work yeah so that that is a great question um I don't know if everyone heard it but it more or less boils down to as far as what I talk about with usability is security how do you incorporate that in the feedback loop user feedback that is difficult especially as depending on how your organization is set up like I don't deal with users most of the time unless something horrible has happened I don't have to deal with them so a lot of it is the way that I like to do things is incorporate your help desk into decisions have a representative from different organizations like within it talk to someone at help desk say how are

our users going to abuse this how is this going to piss people off what you know I'll make a system and then you'll immediately talk to someone in help desk or we call it Tech Ops at dragos and they'll go what the hell were you thinking that's never going to work our users don't don't work that way they don't use that kind of system they don't blah blah Did you consider that we also have Max you know things like that so um you have user feedback is obviously important it's hard to do it you know when we're kind of in these silos but trying to unsilo and use team you know incorporate feedback from teams outside

of just pure Securities is how I usually achieve it