One Man Army - Kashish Mittal

Yeah, hi all, welcome to One Person Army, how to be the first security engineer at a company. Before I start, quick disclaimer. So all the opinions throughout the presentation are exclusively my own and do not represent the views of my employer. So hopefully current or previous employers don't sue me for this presentation. So who am I?

I'm head of security at this team called Mobile Data Labs of Microsoft. It was earlier a startup by the name of MyLikeYou before it got acquired. I've worked at other security companies like Elevate Security, Duo Security, Scilab, Bank of America, and Deutsche Bank. And if you haven't figured it out, this is how I speak. I have an Indian accent. I'm not pretending to be Apu from The Simpsons or doing a joke. So if you fail to understand anything, just raise your hands and I'll be happy to repeat it. So how did I get into security? So I went to this tiny college called Carnegie Mellon. It's in Pittsburgh, United States. And I did a lot of security research at the cyber security lab, Scilab there. So that gave

me a lot of academic and foundational knowledge. And then a lot of my technical, practical skills came from playing CTFs. So for those who don't know what CTFs are, we'll cover that in a bit. But it basically captured the flag competitions similar to security puzzles or security online games that people in the infosec industry play to hone and get new skills. Yeah, and I'm part of this team called PPP. Some of you guys who play CTFs might have heard of us. And yeah, as I mentioned, I learned a lot of practical security through CTFs. So yeah, so let's do some exercises. I think you guys might be lazy after lunch. So... Any of you been in the situation where you had to start a security team or you were

the first security engineer at a company? Okay, one, two, two of you. Yeah, so hopefully you guys will be able to relate to some of this. For the others, you know, you might find yourself in these shoes pretty soon. Okay, any of you who don't identify as security engineers but were trusted the responsibility to manage security? Okay, none of us there. Okay, so all of us have security in the room.

Okay, so what makes me qualified to talk about this, right? So I've had this experience three to four times now. Basically, the experience is building security from the ground up. And my experiences have mostly been in hyper growth and high risk startups. I started and helped build the application security team at this company called Duo Security. I was the founding engineer at another security startup called Elevate Security. And yeah, as most recently I mentioned, I was starting and building the security program at MyLikeU Microsoft. I'll go over all of them briefly. So Duo Security, some of you might have heard of this company. 2FA and authentication company. So as you guys can understand, it has highly sensitive functionality, highly sensitive data. It recently got acquired by Cisco.

So I was the first dedicated application security engineer there. And we were a team of four by the time I left. I helped build the SSDLC cycle. So basically the secure software development lifecycle. And you know it included stuff like threat modeling, design reviews, code analysis, security assessments and bug bounty. The next one was Elevate Security. So I was a founding engineer here. So basically what we are trying to build is a security education and security behavior change platform for corporate security initiatives and you know belonging to enterprise companies. And yeah, so what I did there was build security awareness and training content security awareness platforms and also ran phishing campaigns for them. And yeah, most recently MileIQ.

So for those who haven't used it, it's a pretty nifty app. So it basically tracks your mileage and expenses. So you can claim deductions, you can file tax reports, you can bill your employer or your vendor for the time. And yeah, we got acquired by Microsoft. So I was the first security engineer. And honestly, before I joined, there was little to no security. And yeah, I'm a head of security now. So I deal with initiatives lying within AppSec, CorporateSec, InfraSec and a bit of privacy and compliance. So as you can see, the trend is basically trying to build security from ground up. So basically if you talk in a mathematical perspective, sorry, computer science perspective, basically building security

from zero to one. But if you talk to any mathematician, they'll tell you that there's an infinity of possibilities between those two numbers. And so that's basically what we're going to discuss today. So yeah, so my objective is to share some key learnings and experiences from building these and hopefully it will be useful for some of you guys. So where does the ideology, right? Like you guys have read the title. It basically says one person army or one man army or one woman army. So the idea is that this is a technique borrowed from the military terminology. And Wikipedia defines this as basically saying a heavily armed and well-trained combatant able to face numerous enemies alone. So I want you to pay attention to the bolded

parts here. So heavily armed, so having the right tools and the techniques to be able to deal with the threat actors. Well trained as because this is not like a non-technical job where you can manage without having the technical knowledge and expertise. And finally numerous enemies alone because you'll have so many threat actors, so many things that you have to protect against both internally and externally. So that's where this technique is adopted from. Unfortunately we don't have a lot of female representation in the room but basically the idea behind calling it one person army is that in the military technology terminology it's called one man but it's a equally likely or as likely to be a woman doing the same thing so that's why it's called one person army

and yeah so let's get started with some of the basics quickly um so yeah so just like when you take up any new job You know familiarizing yourself with the organization so for those of who those of you who do pen testing this is similar to the recon phase and Basically, you're trying to figure out who are the decision makers who are the stakeholders? you know what kind of pace you can operate with and from the technology perspective looking at the tech stack looking at the different tools and technologies the company uses and the fortunate thing for you guys is that if somebody has decided to hire you and then at least one person in

that company gets security. Whether it's a CEO, whether it's a CTO, whether it was a person who was doing security even though they're not security engineers, one person at least gets it. So identifying this person or other key associates who get security, so who will act as your allies throughout this journey. So that's the other component. The next piece of recommendation is making an impact early, right? So this is basically showing What value a security engineer brings and specifically you when you're in that position? So my recommendation is catching the low-hanging fruit and what this means is like three to five key wins or key things you guys can do in the first 30 to 90 days and I'll share some of those things that I did at

previous companies so in one case there was a the company had no two-factor authentication and they were allowing personal emails which is quite standard with startups and the password hygiene was pretty horrible so when you when you amount all of this so it basically dictates that one phishing email will be able to take over your corporate network or will be able to take over the data that those emails have access to. So in this case, the fixes were pretty easy. Enroll and enforced MFA or 2FA across the organization. Once the company becomes big enough, you don't really need to support personal emails. By the time I had joined, everybody had corporate domain. So, you know, removing the access to all the personal emails and basically educating

about good password hygiene. So these were the quick fixes here. The second one was account takeover. So yeah, basically there's no logging or auditing on who is accessing your account. And similarly, no 2FA. So basically another phishing email gives you access to takeover an account. It can be an admin account. It can be a CTO's account. All these people within that gambit. So apart from 2FA, also enabling some sort of auditing and logging. So in case something goes wrong, you can at least go back and look at your logs to try and figure out if somebody got unauthorized access. In another instance, we were hosting all our code on GitHub. So any of you familiar

with GitHub or use that for code hosting? So basically, if you've used it, you might know that there is a setting which allows you to irrevocably delete all your code or all your repos. this is a functionality that is only available to a certain set of people but in that organization it was basically given access by given access to through all the employees so what we decided here was that firstly this is an operation that you will not need to do frequently and at max one or two people and to the ranks of maybe your CT or your head of engineering might need this access so removing access to all of that and creating a

backup and in case those two particular accounts get fished and somebody deletes your code you at least have a backup to rely on and finally extracting all our customer data including PII so PII is personally identifiable information so things like your name your address your credit card numbers your SSN so things that can personally identify you so really sensitive data and as you can imagine in a startup this is Probably the worst thing that can happen to you in terms of security like if you are all your customer data is extracted So you're putting in controls to stop that from happening So there's this technique which I've used fairly successfully So it's basically called secure document repeat as the name stands So

you'll find a bunch of insecure stuff in your organization So you go about securing it, but the job doesn't end there you basically document what you secured and you also document what is the correct way to To you know use those things in the future and you keep doing this in a loop So if you take the example of azure vms that you guys might spend about it So when you first join the organization you might see that the vms are not being spun up in the right manner Some ports that do not need to be open are open or some things are exposed to the internet So it's your job to not only secure

the existing vms But also document a manner in which any new developer or any existing developer can spin up the new vms in a secure manner And the reason why we are doing this is the key takeaway as I mentioned, efficiency, availability and repeatability. So basically you don't want to keep spending your time solving the same problem. Right. So it's important for you to like create a standard doc or a procedure that the developers can follow. The second thing is availability. If you're on vacation, if you're out sick or if you're in Liverpool, your developers will still be doing all this stuff. So they need to have some sort of thing to reference even when

you're not physically or in person available. And finally, repeatability. So you can use this process to go about securing your VMs, go about securing your data, your databases, all that stuff. And this process works again. So this is a one stop shop for securing most of your stuff. The other component of this journey, which I believe is the biggest one, is basically education, evangelism and communication. So the biggest part of this job or this journey will be educating yourself and others about security, whether it's the need and importance for security or what specific elements of security you need to implement for your tech stack. The other component that a lot of times we don't do well is evangelizing our work, right? So let's assume we had

a big win, we managed to secure XYZ stuff, but also making sure we are spreading that awareness and that knowledge throughout the organization. So not only do you get like credit for doing that stuff, but it builds your accountability and reputation. So next time when you want to, you know, press on some things, you will have a track record of having done these things, which will help you. And communication is key as in with most things. Unfortunately, there is no one technique that I have found that will work with every person, whether it's your executive team or like an engineer. So you have to try out different techniques some of the things that I have tried out which have helped me so there's this technique called shock and awe

or fear technique where you basically try to scare the skilled holders to say that if you guys don't take action or if we don't fix this stuff this is what can happen a quick example is let's assume you hold a live hacking session or you know you take explicit permission but then you know run phishing campaigns or something of your sort to show the real-world consequences of not having security This technique helps but not in all cases. So there'll be times where people will understand the need for security but they'll just say that we don't have enough time or we messed up in the start so can you help us now. That is where you need to lend more of a helping hand. An example I can remember

is an engineering manager coming to you a week or two before an important release and saying can we wrap up the security around this so we don't miss the important deadline but we still are not shipping an insecure product. So even if you have to go out of your way there. So that's one thing. And one other thing to be careful about here is you can't really communicate sensitive things in a public manner. So there are some things where it's okay to post it on Slack or post it on Teams and let everybody know. But there are some other information that you will find which needs to be only shared on a need to know basis. So for example, if you find an exploit or if

you find a possible vulnerability, it's not advisable to just share it with all the people even if they are not directly stakeholders there. So a part of education is workshops and knowledge transfer. The key here is to make sure you're focusing on both technical and non-technical employees. Examples include stuff like developer security workshops that you guys can hold. So one of the ones that I have held in previous companies is called security is incomplete without you. And similarly, security 101 training for people who are not very familiar with security. It includes basic stuff like phishing, malware, passwords, so on and so forth. And the other one that I ran for this was basically how to keep yourself safe at work and

at home. So next component is developer empathy. So what this basically means is, you know, it's new for them. most probably have to do it before you join especially in a startup this is actually one of the quotes from one of our developers I had spoken to basically saying security like we don't have to do that earlier so why are you coming and bothering me now and yeah the other component to understand is that in most cases it's a really high pressure job for them like they're working at intense paces and they have really strict deadlines in a startup you will always face this so just like in security we have a trade-off between usability and security startup you always have the state of between making the

current product better versus adding new features to it so you have to you know maintain that balance and make sure you know you're not acting as a blocker in new releases yeah so there's one component that I think a lot of us struggle with which is basically to say like what motivates your employees or your organization to do security in a lot of cases we assume that they are not able to do it because of lack of technical skill or lack of understanding but in a lot of cases it's also about whether they even care about security and so one way i found that helps out with this is the security champs program the idea behind this whole program is to get your

organization and employees to want to do security rather than being forced to do security so i'll quickly go over this in interest of time so yeah so this is basically non security dedicated employees helping out with security stuff so let me break that on when I say non security dedicated I say that because I believe security is everybody's job so there is technically no non security employee but people whose primary or only responsibility is not security so people belonging to HR finance legal sales and so on and so forth It's also called security ambassadors or security satellites program at some places. And the closest analogy I can find to the real world is basically the police of a state or a city asking its citizens to be its

eyes and ears, right? So you guys would have heard of things like if you see something, say something. If you see on the tube system and the railway system, it says see it, say it, and we'll sort it out. So along the same lines. And again, emphasis on both technical and non-technical employees. How you build a team about this is basically you want to have ideally a security champ per individual team like one for marketing, one for finance and so on and so forth. If your guys are geographically in multiple locations like we are in Seattle, San Francisco, Bangalore, Europe, all these places. So you would want to have at least one representative per geographical location and ideally not more than

20 full-time employees per one security champ because otherwise it will become hard for them to manage it so yeah and the key component here is getting some sort of executive sponsor uh this is a person in the executive team who has some organizational power who can you know help you out with organizational buy-in and so on i'm going to quickly go over the rest because i'm running out of time so what are the responsibilities basically acting as the first point of contact driving security improvements within the team, engaging the security team whenever it's required and spending about 10 to 20 percent of their time. They also improve their security understanding and awareness in this process.

Some of the perks that we've successfully offered to get more buy-in is basically people really want to enhance their security understanding, especially given security is an upcoming field. So even if they work in sales, it's going to help out in their career. The biggest part that we've seen work is appreciation from coworkers and leadership team. That's something that really drives employees. And yeah, like swag such as t-shirts, stickers, goodies, and free food during meetings. So what does this entail? So this firstly helps you build a security culture and mindset amongst non-security dedicated employees. It will help you build the organization's culture, security culture and also help you scale security. So when you're one person or in a very small team, it's hard for you to scale security

as the organization grows. So the next component is automation and alerts. Similar idea, one person, you can't manage everything, you can't operate a SOC or monitor tools 24-7. So set up meaningful and actionable alerts and have them guide your response and basically see in what situation you really need to see those alerts. Build versus buy. So basic idea, no need to reinvent the wheel. There'll be cases where products will work for you out of the box or in the standard configurations. make sure to try and use them even if they're slightly more expensive because they will definitely be cases where you're working on custom tools or custom interactions where you know there are unique characteristics to your organization or your tech stack where standard stuff will not

work so you need to focus your time and attention there yeah so an example I can think of is the Azure Security Center so basically it gives you Key Vault which will help you manage all your passwords all your keys all your secrets all your certificates so you don't need to build any of that similarly the security center gives you protection against DDoS attacks UDP flooding attacks so you can use that in the firewall and most databases that Azure offers will give you the standard data protection techniques that you need so for example encryption at rest encryption at transit IP whitelisting so on and so forth so the idea is instead of you relying on

a custom database where you have to build all these features or using a database that does not support these security features try and use one that does because it will make your job much easier and you can focus your time on the rest of the stuff yeah so this is a technique which is taught to be my by my mentor basically it's called the ipad signing technique so the idea is that if you're trying to get some work done which is security critical in your understanding but you're receiving pushback or people are you know, not ambivalent about whether they care about that or not. So basically you walk into that room or that meeting with

an iPad saying, okay, I have explained the security risk to you. I have explained that this is what's going to happen. Can you sign off on that risk? Right? So that's basically the iPad sign to me. In all my years so far and my mentors, it has never been the case that we went in with this strategy and we did not get a fair shot at what we are trying to do. And basically the reason behind this is that no one wants to individually be responsible for security risk consumption. So they will at least give you a valid hearing and understand that you are serious about this. So this is something. A caveat I want

to make here is that We've seen cases where security leaders and professionals have been fired or done wrong with because of sticking by certain ethics. So examples include not wanting to pay out an extortion from hackers and stuff like that. So make sure you guys are safeguarding yourselves if you're in those situations. Making sure you're giving the right feedback to multiple stakeholders. So if one person decides to do something unethical, you guys are not going to be held accountable for it. So we talked a lot about developers, so let's talk about a bit about corpus-sec initiatives. So basically phishing, so think about 2FA versus YubiKeys. So YubiKeys basically support this protocol called U2F, Universal Second Factor or Fido, Fast Endure Line.

So see which one works for you guys better. Passwords, so you're making sure the password hygiene is good. Malware execution, basically your employees downloading something and running it. without knowing what it is and access control around data. So who needs access to what data and what level. The next point is basically security training and awareness. So for most employees and most companies we found out that the current methods are not great and training generally needs to be customized to get maximum return on investment. We discussed about motivation, so it's important to motivate your employees. What we've learned is that active and experiential learning is better than passive at retention. So if you run a phishing campaign or if you give them

some training, you might want them to retain that learning throughout the rest of the year because they can be attacked in the real world at any time. And yeah, so if you find CTFs interesting, try them out. And yeah, this is some non-technical stuff. So basically, before you decide to say yes to that job, there are some things that you guys might find useful. Firstly, making sure you have some sort of alignment with the upper management, whether it's your hiring manager, whether it's a CTO, whether it's the CEO. So figuring out what is the motivation of the organization to ramp up security, which earlier was not there and why you guys are being hired now. You know similarly looking at goals, so are they looking to achieve a particular

compliance? Are they looking to get something done? Is it only because they recently got breached and now they started caring about security? So all these things also talking about timeline and budget so basically saying where do they see? The security program going in 3 6 12 months and also you know what kind of budget you are working with so you you know you can play around with tools and stuff like that and finally headcount and So if you live in San Francisco like I do, hiring is a big challenge. So you have to be creative with hiring outside US or maybe in the Europe or Asia market or basically employing consultants. So yeah. And yeah, the last thing I want to say is that just like with most

jobs, it will not be rosy ride or all rosy. You'll have tough days and frustrating days, especially at startups because you might be working on a particular product or a feature or securing something for the next for the past three months and you'll find out that it's been deprecated or it's not even been used anymore so you know you have to roll with the punches there and yeah as long as you remember this goal that i stick by you'll be fine so basically the idea is that you have to secure the organization to the best of your ability and resources and yeah any questions oh looks like it's good thank you