Overcoming Obstacles in Operationalizing Security

[Music]

all right thank you very much let's start all over again so good to be here good morning everybody so just some housekeeping notes this is not the talk about browser injections in JavaScript if that's your cup of tea I'm told that's in track one which is a really cool IMAX theater you can check that out it's also not to talk about the meltdown and memory exploits if that's where you'd rather be that's the talk in track three which is theater seven so if you are still in your seats that means you're in the right room we're going to be talking about overcoming obstacles in operationalizing security I'm really really excited to be here and talking to

you about that so a little bit about what the talk is gonna constitute I'm gonna introduce a little bit about me I'm gonna introduce why we are doing this talk and then it always helps to define the problem right so I want to make sure we all understand what is the context within which we are operating and why I thought about talking talking to you about this topic and then they're gonna go really specifically into some of the obstacles that we are here to talk about and not just leave you with those obstacles but also try to discuss what are some of the approaches that we can use to overcome those obstacles and hopefully we'll have some time remaining

for question and answers so you already heard a little bit about me so I graduated from Purdue University a little over 10 years ago and then I worked at a variety of companies that are shown here so I've worked as a researcher I've worked at a security developer I've also worked on the consulting side of things on the audit side of things and then most recently did did a gig at a startup where well at that time a start-up and help them become become of a public company as a manager responsible for their security and compliance efforts and currently I'm with the healthcare startup healthcare where I'm leading their security program I also teach part-time at Santa Clara

University where I teach a graduate course in information security why do I do that because I realized that there is no formal education patient in this area and therefore you know we we all learn from experience and so I would like to share what I've learned from my experience in in you know mentoring the next generation of security professionals okay so with that said why am I here to talk about this topic today well so when I joined healthTap I thought that okay I've seen it all I've been there more than 10 years I've looked at it from the inside and the outside I've worked at companies both large and small so what can go

wrong right except the fact that I had never worked at healthTap doing the same type of thing that I did there which is building a security program from scratch and so I learned a few lessons along the way and I would like to share them because I realized I believe I'm not the only one who has ever done that or will ever do that again and so I think it'll be helpful for everyone to to understand what it the process might look like so this talk would begin where most other talks on this topic usually end which is you know that we we are told that okay we need to learn how to communicate risks we need to get buy-in from

stakeholders and we need to you know we need to project security as an enabler and not a blocker that's all good but what I wanted to convey is what's usually not discussed which is that unless you have been in the trenches you wouldn't know so hence the analogy between MapQuest and waves maybe some of you already got the analogy which is you may know the direction right one of these tools is going to give you the directions to get there but one of these tools is going to show you the obstacles along the way and then you can steer your course around that so the takeaways for you will be what obstacles to anticipate and what trade-offs you can

make so with that said let's let's get into the problem statement and try to define define you know what I'm going to present to you when you are when your job is to start a security program at a startup typically that you know that what is the textbook ask you to do it will ask you to look at these variables you need to define your risk surface typically you do that by threat modeling you need to understand what your resources are which would include a mix of budget resource human resources you know talent and tools and then you need to see how those resources map to your capabilities so that's all fine and good there is

another element here which is the rate at which these resources change and they might change linearly or non linearly a little bit of college algebra there so throwback twelve months when I started the program at healthTap I did exactly the same thing I created like a road map like it's 30 60 90 day plan as you would expect I would hit I would anticipate that I would hit certain milestones by a certain certain time period and that would help improve the security maturity of the program classic textbook approach this was underlined by a linear assumption and a linear assumption a you know basically works as follows the prong one is that the resource availability is going to adjust itself

based on the risk surface so this is where your your traditional approaches come in you present a risk report to the management you walk away with the dollars and then you hire the employees that's all that's all fine and good the second approach is that the capability is also actually improve in response to the resources that you get right fast forward a few months I quickly realized that the reality is nonlinear which is as shown here if you notice my security roadmap I wasn't actually able to add resources as fast as I had anticipated to to address my risk surface and that red line over there indicates the reason why because if you see in the middle

column I have a few items that are still not in the completed State despite those periods actually being being over and so what that really means is I hit a negative slope this is why the linear azar chan fails because the risk profile did not adjust itself or the resource allocation did not adjust itself based on the risk profile so if you are starting a security program at a startup you are going to hit a negative slope and you should be prepared to first zero it out and then start with the positive the second important prong is that even if you get the resources that you need it is not always going to mean that it

translates into the capabilities that you need to address your risks and therefore it's an important combination of making sure that you get the resources and the capabilities we will get back to this point about making sure that you you hire right and it's a good mix of talent and tools but for now you might wonder that when I when I got the stark reality stark contrast between the textbook approach and what's the reality you might wonder if I was scared and you bet I was however I also wondered if why why else aren't we talking about about this right and quickly it all began to make sense we are all part of the security community the same security

community just working for different organizations at different levels of maturity we talk about what mature organizations have done but we don't talk about the struggles of them getting there if you are starting a security program at a startup you would find yourself on the left to the middle of this curve and this curve can be considered as a bell curve of the relative security maturity of the organization's right and so when you are planning for for your you know security maturity you would have to look at it it helps to get a sense of how far behind you really are and and that sense that can that can be actually scary but at the same time you got a you got a better

understanding of what is the what is the security maturity that you will actually be that would actually be trying to achieve and knowing where you are on this bell curve is is really important okay so with with that said I wanna I wanna I want to start with this realization that there's a big gap in terms of the effort required to lay proper foundation of a security program so with that said ladies and gentlemen it's time to start your engines if you cannot build a Ferrari or if you cannot build your own Tesla given the resource constraints let's start with the Prius okay but there is an upside to this and the upside is that you should consider

yourself lucky that you got an opportunity to go through this challenge because you don't get a greenfield opportunity every day and that is where rubber meets the road so with that problem statements that aside let's let's try to dive into what what are the some of the specific obstacles that that you might that you might anticipate that you might face and then how would you might overcome them so I'm gonna start with the first one which is picking your battles wisely so the the textbook is going to throw tons of stuff at you right and it's very likely that when you are starting a security program you're going to do some research you might even need to catch up

on some trends right but be careful because the lenders are going to create a lot of hype for you they're gonna be a lot of buzz words out there and so you know the vendors are gonna remind you of the worst breaches but keep that in context understand for example what the breach stands for if someone you know what helped have what I started to do was I started to publish what are called security advisories I would take a breach I would see exactly what happened what was the risk is that same risk applicable to my environment and what can we do to protect that that is the more helpful way to to internalize what's actually important to you based

on what's happening around you similarly you're gonna be looking at tons of alphabet soup you know you're gonna be looking at you know from a compliance perspective you'll be looking at GDP are you gonna be looking at AI ISO again just because of those buzzwords don't fall into the trap that you necessarily need to invest more a lot of times what's important is you do a base lining and this is this is where your traditional approaches will help you but it's important too to do that base lining because it helps avoid duplicative and investment you mean you may not realize but a lot of these controls and all these regulations are actually hitting at the same underlying

security fundamentals and if you got your fundamentals correct it is my it is my belief it is it is the way I'd like to operate that if you have your fundamentals correct you're probably gonna hit all those all those checkboxes so the lesson here is not every bright and shiny seal is worth the paper it's printed on I have been defending you know various requests for getting one seal versus the other with my management and sometimes you know this is this is the reverse cycle where I'm advocating them not to spend more money we will talk more about how that helps you gain their trust in just a little bit so let me give you some specific examples of

these trade-offs right one thing I also like to mention is that you may also want to find if there a simpler approach of doing something and the answer is almost always yes we'll see some examples coming up as well and then don't ignore the low-hanging fruit right where which the things that you can knock off without significant resource investments and some examples on this slide so speaking of trends you might see you know attack simulation red teaming bug bounties we even had a you know keynote on bug bounty or earlier this morning you would have to really understand whether or not you are at a stage where all of this makes sense to you or not

right so in terms of attack simulation and red teaming that the and try to understand what the purpose is there understood the purpose is if your controls are actually working effectively but if you don't even have the controls right it's kind of like the prerequisite of that is you need to have some controls in place so why do that investment again when you can wait and see if you have some controls that are operational and thence investing in these tools similarly for bug bounties their purpose is to expose vulnerabilities ask yourself if you have a process in place to do something with the vulnerabilities are otherwise wait until that process is in place some other buzzwords like Web

Application Firewall DDoS protection you need to ask yourself is your technology or is your application built on a modern technology with security principles in mind that make valve type of protection you know still relevant or not if you're already making if your application has already built on a platform to which the vast protection does not apply you need you don't need to fall for them for the buzzwords are you a likely target are you so you know are you so much at risk of being a likely target of a tacit AK this is this is a question worth having or are you in a platform like AWS where you you have basic protection to begin with and then you need to start

worrying about it when you when you scale to a level where you are a likely target so once again you know these are all the buzzwords but we but we need to internalize our own priorities and understand where we fall I want to give a really specific example about endpoint protection because EDRs and you know threat hunting this this is the rage these days you need to you need to understand whether or not you need a fully managed solution or can you do it a combination of manual configuration with auditing so at healthTap while we are small enough the approach that I'm using is we have something called this user security checklist so it's not just

about the price point but it's also when you ask the users to do these 10 things when they when they on board it gives them a better awareness of what the risks are as opposed to getting a device that's like out of the box configured with with 10 things that they don't even you know are not necessarily aware of so when the users go through those 10 steps they get an increased sense of awareness of you these are the important things and then going back to the security advisory I regularly publish when a particular breach took advantage of a particular thing on my list that was not done properly by a user you know like two-factor or some other

example going back to that how generating awareness I would like to point out that awareness training is almost always going to be an immediate priority it's just a matter of how you approach it right I feel that as a community we need to give more love to awareness training we need to do that in a way that actually helps promote security culture so for example that help tab when I when I joined we were using a off-the-shelf software to you know do security training and you all know the feeling you go through it you know you click different links but what I what I decided to do was I decided to prepare and deliver that training

in-house and that has had a significant impact on you know the awareness and culture of the employees and making sure that everybody is actually aware of the value of why we are doing that so that that's another example of where you know with a little bit or next to no investment you can you can get it get it get a lot of value out of your security program so the next point I want to talk about is identifying your allies and gaps early so obviously you would know that you cannot go the whole nine yards alone right that's what the textbook tells you you know David asked you to identify the collaborators identify the department's but what they don't tell

you is what if the department you really need to get something done doesn't yet exist okay so the answer is you become that department will we'll discuss some specific examples but the show must go on the other thing that you should be mindful office do more but expect less to be done for you okay so often when you come from large companies there are specific people responsible for doing specific things and you are in the habit of you know delegating certain tasks but when you are at a small start-up you should you should be aware of the fact that you may not have too many people to delegate those tasks so the textbook will tell you you know

you know yet you have to be hands-on you have to be an enabler but that doesn't always mean getting your way you know the textbook tells you get the buy-in but what does a buy-in really mean right so my answer to that is impress them with your judgement and then money will follow so let's talk about some specific examples of these trade-offs right so essentially the idea here is that you have to chart your own process when I when I started there there wasn't a robust enough process for us to be notified when an employee is joining or leaving and rather than waiting for you know a full-fledged work the implementation to be there I took

advantage of simple JIRA based workflows I tied them into whatever system you know wherever a notification is triggered of a new hire of a hire you know joining or an employee leaving I connected that to like a ticketing system there you know some tickets will get generated some spreadsheets will get populated same thing with IT most likely you are not gonna have a very robust IT when you when you join a small startup that is going to take care of your identity management needs that is going to make sure that all the identities are streamlined all the access is you know provision and deprovision timely you you will probably need to get up to speed on

those workflows there are a lot of tools out there that can help you with that but rather than waiting for you know an IT or an HR system implementation just just be more creative about that and and make spreadsheets your best friends make JIRA tickets your best friend and build some build some tools around that how about actually implementing security features and building that in your in your you know product lifecycle so you might be used to working with a product manager who's going to write the spec specification for you and then follow up on that but the reality is that there may be no project manager so you have to be the one who is writing the specifications

and keep pushing the product team to pick it up remember that there will always be plenty on the product roadmap that you are competing with so you have to stay persistent in my experience it took me several months for some of the features that I really really wanted to go into product roadmap to finally get in I kept getting you know it's it's it's gonna be the next and then the next and then the next release but you need to keep the pressure up and at some point know when is the right time to escalate and then remember we talked about how the resources don't always translate into capabilities so even if you have funding

you need to get some tools you need to roll out some tools in your environment to be able to take advantage of that but if you don't have procurement what do you do well going with the trend you become the procurement you need to learn the art of negotiation you need to build the trust to be able to do the right thing in my example I did a negotiation for an access control system and you know I was thrown into that that situation even though that was not my primary responsibility but after I had done it once and I did it successfully guess what I earned the trust of the management and now I I go in with a

request and they they trust me that I have already negotiated down to the most acceptable price okay so the other point I want to bring up is the tension between advice and practice so often times when you know we are looking at the textbooks we learned that you know training the developers is important train as early as possible in the process and making it you know delaying that it's going to make things more difficult for you and in reality your mileage will vary the key is how much of an opportunity you have in the software development lifecycle to do a careful review and no amount of training can actually compensate for the pressures of releasing often and early which is the

DevOps mantra so I'll give you some examples on how to trade that off the other thing is the textbook tells you write detailed specifications get them reviewed and approved before the code is written and the feature is implemented good luck with that because building it when you're joining a start-up you're pretty much building the plane as you fly it and a really good metaphor that I'd like to use there is that specs are like guideposts not gospel deviation may be expected and lastly you know the classic example of when to apply or delay a patch the textbook tells you that do not ever ignore a high severity CVE but in practice there may be competing trade-offs the system may be

on a critical path you cannot afford the downtime there may be no redundancy so how do you deal with those situations so going back to our examples of these trade-offs with respect to s DLC you should balance the training with tools what we did is one of the earliest things I did was you know based on the application security testing we did we identified what are the most frequent flaws in our code what are the most frequent mistakes the developers are making automate the checks for those those type of issues in your you know static code analysis tools and then prepare guides like really handy guides not like long lectures that help the developers first of all understand and

realize that hey yes we are making these mistakes and we need to improve and that gets the message across very effectively the other thing I'd like to talk about is you know do not underestimate the power of nudge so there's a thin line between when the employers are you know going to co-op whether the employees may cooperate with you versus consider security as becoming too intrusive and so nothing can help you know a little bit of nudging can help them even when compared to an army of security tools at our disposal so for those of you who don't know nudge is actually an you know an economic concept it's a nobel-prize-winning economic theory and even though in this context we are not

talking about economics but it's still relevant to the ROI on your on your security investments so I'll give you an example DLP reminders so although I believe that a DLP tool isn't necessarily making you know a significant contribution towards improving my security baseline however the DLP tool has this nudge factor every time you know we detect sensitive information being shared which we don't know is with a user who actually you know has a purpose to receive that or not we send a reminder to the user that hey please take a look is this information really necessary to be sure to this person and with this way with this nudging it gradually will inculcate an awareness in our in our

employees that they have to be careful every time they are taking that step and that's also a good compromise between you know clamping down on all sharing versus making sure that your user base is educated on proper awareness one thing I would like to also emphasize is it's okay to give unsolicited advice you are working in an environment where you know the feedback loops are not streamlined there isn't enough opportunity to for the teams to recognize or to request help therefore you know don't be afraid to offer advice when needed if the Specht has holes go ahead and fill them there is there isn't going to be a security checklist waiting for you to put your stamp of approval on it's up

to you to insert it where it's needed you know the best where where security checks are needed and make sure that you you provide that advice at the right time and lastly on the topic of you know when or when not to apply you know a critical fix the idea is that if it cannot go and immediately make sure that you are monitoring it and monitor the known vulnerability it is a reality you will be running with some percent of vulnerable systems you you cannot be not vulnerable at all times so continue to identify the first available opportunity to to fix them and then my last topic is going to be by what you must and build

what you can this is kind of like the most common sense of all the topics that we've talked about where you know that the textbook comes fairly close to reality but there are just a few things that the textbook doesn't quite lay down for you so there's always going to be a right combination of tools talent and training what I really wanted to emphasize is don't be afraid to go with modern or newer vendors because oftentimes there's a tendency to think that you know only the established and entrenched players are the ones that you want to go before but with startups there are two reasons why that may or may not always work out they may have some you know they may

have like a lower limit of like at least how big of a company if they want to work with and and you'll be out of luck there secondly discuss your use case with them and you may be surprised that vendors can sometimes be unbiased consultants or advisers I've had this experience where the vendor would very frankly talk about their own technology and say that hey they're using all these buzzwords this part of it may not be true may be may be exaggerated but this is our real value so and often times you know I know that we we want to show we want to stay away from talking to salespeople but if you if you're looking

at a like you know smaller vendor you may find yourself talking to engineers you may find yourself talking to even the CEO and you can have a really candid discussion and I have personally really taken advantage of that fact so don't shy away from doing that the other is to put things between the DIY versus the bio buckets again it's kind of like a common-sense thing but the point that I wanted to bring across here is that you know make sure that you take into account when you when you on board a tool make sure that you have the resources you have the right kind of talent to support that or make a decision between that the tool that has

just enough capability to keep you going right that comes with the built in features and then you have the remaining amount of resources on hand to kind of fine-tune that tool so for example if you're making investment to an open source tool or rather if you are not making an investment and using an open source tool then you'd have to make an investment into the human resource but if you don't have a human resource then you would go with some something that gives you a little bit to get started with you to chew on and then have someone that that can take it take it from there so that's that's kind of like a common-sense thing but I just

want to touch upon that in case that you know in case that doesn't doesn't get ignored and it's important to know where technology will give you advantage so automate where technology will give you advantage and then rely on manual efforts where it's best stood suited for example security analytics or pen testing type of work and a few examples right here would be when we are when we were looking at our including detection system we wanted to see what's the most cost efficient way so one way for you to do that is to not have all of the raw data being fed into your sim maybe using maybe use another service that's gonna give you you know an analyzed

feed off of threats and then have put you know you can direct that feed into into your sim similarly for a mobile device management I was not a fan of the huge service and implementation fee that the large vendors charge and so I I'm inclined to go towards a system where once again going back to the user security checklist you have a trust but verify approach and so you know you would trust the users to do the right thing but at the same time you want to make sure that you can audit them frequently enough and while you are at a scale where it can still be effective and lastly Identity Management you know are you one of those environments that

absolutely don't want to have ad in your in your ecosystem if you're in Google cloud go with a cloud-based LDAP that connects directly with with the identity store and if you are if you are cognizant of the per user and implementation fee for having you know an identity system for you know entire organization focus on the most critical subsets first so for example I took a I took a turn on on that and instead of you know starting with the whole the whole company first I started to focus on just an engineering team and just focusing on the infrastructure and decided to go with the vendor that is going to help me with the infrastructure

for and then and then that can be explained to the whole company and that really brings a lot of cost savings for for everybody so I think with that I would take a pause and see if there are any questions but thank you so much for being here today

sorry can you repeat the question yeah so I think the question of so the question is with you know after all that education how are you going to improve on the hiring and retention so that is that is something that again is part of you know the nonlinear nature of building a security program and that is something a little bit more on the on the personal side of things then then what you can put in terms of you know practical steps to you know directly affect the security maturity of the program but you know the hiring and retention obviously is a challenge for for all security you know for for all companies particularly in the Bay Area

but I mean to to that effect I would say that having having the right balance of you know tools and resources on your team and making sure that it's not one person's job to to be you know the end-to-end you know a soldier for for every single thing that for me it has been something that I've noticed as a red red flag so don't don't burn them out and then making sure that you know you are you know going back to what I said about creating incentives so making sure that employees are incentivized for for bringing forward good security practices but at the end of the day I mean it is it is a key

challenge you know hiring and retention is something that you know is it's kind of like a broader thing than just limited to a security program so but as a security team you can you can you can do a lot of things by making sure that you are not over burdening any any single employee with a lot of responsibilities and making sure that you can hire right making sure that they are passionate about the role that they're doing and you can you can do a lot of that planning but it's it's it's it's unfortunately something where the results are not always guaranteed I

think there is one more question yeah

that's a great question the ratio of Junior versus senior is something that is is a really critical critical piece and on my team right now the people who are dedicated to security are relatively junior but the people that are indirectly helping security but are not dedicated to security are senior people so I would and again hiring senior people in security you know going back to the previous question is going to be challenging for a small small start-up and therefore you know leveraging as much as you can from senior people that that are not directly on part of the security team is going to be very helpful so for example your DevOps team make sure they are your best

friends the one of the first things I did was you know make strong connections with that with that lead DevOps person and make sure that they are aware that how every move they are making directly or indirectly impact security and therefore to answer that question yes it's it's going to be a challenge to have a lot of senior people in security on your team directly but make sure that you have good connections with senior people in related areas like DevOps and engineering and make them indirectly part of your your security agenda all right I think I'm the last one standing between you and the lunch so I'd let you let you go and and have some had some lunch thank you

so much it's been it's been awesome talking to you okay Thank You Raphael and in the name of the adobe and beside let me give you this