Social Skills For Information Security Professionals: On Agile, Secure SDLC and Unhealthy Habits

Chapter 2

of Social Skills For Information Security Professionals: A Handbook For Those Who Want To Lead And Manage Effectively

__________________________________________________________

Agile implementation of security into a corporate culture

Start small

I recommend you to take baby steps with all of the security initiatives you want to start at your company. By balancing the workload and adaptability you can demonstrate coworkers and executives that security doesn’t need to be tangled and complicated. If you show people that it takes just 5 clicks to enable disk encryption to improve safety of their PCs, it’ll be easier to have discussions with them in the future. After you’ve accumulated a few such small-wins, their mindset will change and they believe there actually are hassle-free solutions to security, they’ll be more eager to implement more of it.

Focus on the small wins and do the things that have the biggest ROI(Return Of Investment) and lowest cost of implementation and then steadily increase the complexity of security requirements.

1% is always better than 0. Small win executed today is better than an ideal win executed never.

 The common mistake I’ve seen is that we try to start out too big. We want to enforce all the security rules as soon as possible and sometimes even worse - all at once.

This approach may sound reasonable from a security pro’s perspective, because time is all we’ve got and each minute with security exposure is a minute an attacker can get a foot in the door.

However, it’s a complete failure from a practical business POV and I haven’t ever seen it being successful in the long-term perspective when someone tried to execute too many and too complex things at once.

Human beings are wired in a way that makes them dislike leaving their comfort zones, because the primitive part of our brain was programmed to keep us alive by avoiding risks. In order to fight that, you must give people a tangible incentive for them to take a leap, because they must justify in their own heads why this particular risk is worth taking. Bigger your demand is, bigger the incentive should be, because the potential gain must be big enough for people to fight back the alerts their primitive brain is giving them. Yes, although nowadays we’re rarely required to make decisions that can kill us, that thing still resists when challenged with something new, because it doesn’t understand that discomfort . All it knows is that it must protect us at all cost, and it’s up to us - or actually other parts of our brain - to take a brave decision regardless.

It’s a good idea to start smaller with things that don’t push the comfort zone that much to earn the trust of your people. Most people are open-minded, but not that open-mindedly stupid to be leave their safe spot on the day 1, when they don’t know how good of a leader you are. And that’s for a good reasons, it’s not them to be blamed. People just want to be safe and we should respect that.

An example may be a common situation when you want to start implementing Principle of Least Privilege within your organisation. You shouldn’t just cut off coworkers access to all of their productivity tools, they were used to utilize on daily basis for the past few years. Do it in many small stages, one tool after another in reasonable time spans, otherwise you may outrage people when they lose access to things they were used to use freely. Not only it may cause them a discomfort but it can negatively affect the business when people’s morale are low, and their productivity is lower because they don’t have the tools they need to get the work done.

Building security is tough, not because it’s that technically complicated, but because it takes a lot of time, perseverance, patience and leadership skills. If you’re joining an organization that’s been on the market for a couple of years and never had a security person/culture before, you must prepare yourself for slow rollout of all those great ideas that you have.

It’s because people, who were never trained to be security-savvy, will have hard time adopting new requirements , even if you have reasonable justification for it. People like what they know, what they tested and know to be working and what feels like right for them. Because of our recklessness and mistakes we’ve made in the past 4 decades, we have earned not friendly reputation around infosec. It makes a lot of engineers think that security will make their work suck, so they do everything in their powers to stay away from it.

The best way to build credibility and have immediate results without irritating people is to start with subtle changes like showing the value of strong passwords, password managers, 2 Factor Authentication, Antivirus and frequent software updates . It may sound like nothing, but all adopted across the whole fleet will result in good security baseline that already puts your company in a few TOP % of safest companies. Even though those are the basic things and infosec folks like to go for fancy and overhyped security measures, I can count on fingers of one hand companies that actually have implemented above mentioned basics and done patch management right. That’s just an example tho.

That’s it, starting small is important. You won’t get much love for 30 days password expiry, enforcing security product with terrible UX or for cutting off access to critical services, just because you haven’t done good enough research to learn what is it, that people need to get their work done.

Start early

I can think of at least two main reasons why it’s reasonable to start with security at the project’s earliest. One, is that if you create a security culture in your organisation from its early days, you won’t give people a chance to learn bad habits of ignoring security. Second, is that it’s more expensive to change architecture design and refactor a finished product. Changing habits which essentially is rewiring brains of your employees is a very expensive ride, so it’s better to avoid such challenges altogether and instill security from the employee number 1. Everything that’s happening in the organisation is CEO’s responsibility and if she/he doesn’t set a healthy tone from the day 1, it’ll be hard to teach people to follow the practices, if they know even CEO doesn’t walk the talk.

I recommend all-sized businesses to look for the help of security consultant as soon as it becomes affordable. I wish more companies realized that asking for a few hours of consultancy won’t ruin their budget, but can have tremendous ROI. It can create a baseline upon which they can build their stuff securely from the day one and avoid costly refactorings or breaches in the future. Chances are that if you give it a thought, you’ll remind yourself that you personally know some security passionate who’ll be more than happy to support some startup free of charge in exchange for business experience. She/he can help you ensure that products are well secured, so people in need should reach out to their social circles and ask for help as soon as possible. It costs them nothing, and even if they find a kid who’s been studying appsec for barely 6 months and can work for you only part-time, it’s still better than doing nothing at all.

I’m writing this to demonstrate two important things we don’t pay enough attention to. If you’re a security specialist and someone is asking you for advice, you should emphasize the importance of starting early. Because if you eventually end up joining that company in the future, you don’t want to start from scratch and waste your energy on solving problems that could’ve been prevented from happening in the first place.

The other one is that when you join the company, expose yourself as soon as possible. Don’t close yourself in your office focusing solely on technical aspects such as deploying monitoring and pentesting the infrastructure. Go out there, and show people that you exist. Allow them to notice you, and give them relevant resources as fast as you can. Provide them with books, articles, tools, guidelines, checklists, procedures so they can already start applying it in their day to day work. Thanks to that the improvement will be happening in the background, when you get back into your zone focusing on other things.

Outline SDLC/NDLC improvements

Security should be perceived like any other cost of running a business

Security shouldn’t be seen as an addition to the product development. It’s as regular part of a business operations as anything else, especially when we’re talking about companies that develop their own software.

At software companies, ensuring security should be considered as a part of Quality Assurance, not only because security triad mentions Confidentiality, Integrity and Availability out of which 2 are heavily linked to the product’s quality. So there is that, but also nowadays customers demand products to be safe for their personal usage and professional usage, because they don’t want to buy a service which may have negative impact on their business operations. We’re living in times where we’re all connected to each other like never before and not a single company can exists on this planet without affecting others in one way or another.

Although it may sound obvious to you, it’s not you who I’m concerned about, because we - security professionals - can’t do anything on our own and the perception of all parties involved matters. You must instill security into organisations DNA in such a way that people truly understand what it is and how it matters, because it doesn’t really matter if you have triple-firewalled PC with a personal guard watching over your computer when you go to the toilet, if there are employees who think it’s fine to download pirated games on their corporate laptops.

Also, middle-management is much more eager to spend resources on security, when they perceive it as a regular, necessary cost of software development. There will never be enough money and time to invest in “additional” activities, so you must rewire their dictionary. Security is often called a no-ROI time-waster which adds complexity and slows down development process, so not only security itself costs a lot, but it also makes other things more expensive.

Unless you explain how and why security is important you may have hard time pushing security related changes into existing SDLC processes, and that’s fair because everyone has their own work they’re ought to protect. That’s something you got to really understand, because most often at the workplace importance and urgency, don’t come from inner virtues and passions, but from the actual business impact. So that’s something you must comprehend to shift your mindset and help everyone across the board understand what impact may insecure product have on your business, because except of us, no one is there to do security for the sake of doing security.

 Hold them accountable to high standards, but keep your expectations low

Settle down on how much resources can be dedicated on security improvements, bugfixes and alike.

Discuss how many hours in each development sprint can be dedicated for security and how much free bandwidth does engineering have for potential unexpected security patching. Write it all down in internal documentation system or some other place that allows you to have an official proof that you had those discussions, so that no one can claim that you’re expecting them to do something they hadn’t agreed upon and twist out of the commitment. Each big goal is achieved by making many small steps, and altho it may look like some things should be done all at once, it’s most often not the case in real life. If you properly dissect your projects into smaller tasks, you’ll realize the value of small incremental changes and that big projects not only suck for time management, but they also tend to create a lot of friction with coworkers.

Focus on small but constant improvements, so you have the big goal in back of your head, however you don’t expect people to deliver it all at once. Not only it’ll make execution your projects on time more feasible, but it’ll also reduce the stress and boost team’s morales when they see 100% execution of a small task, rather than 0.1% progress on a huge project.

Let me make one remark here tho, because you really need to be wise when creating your expectations and demands. It’s not reasonable to expect business to stop all money-making activities and focus entirely on security for a few days or weeks to fix identified vulnerabilities. Use risk management to help business operate and help ensure it’s longevity instead of expecting impossible.

In my experience, it really makes a lot of sense sense to establish a fixed amount of resources that will be spent on ensuring security in each product’s release/sprint.

Sacrificing 3% engineering resources each day, is less painful than telling customer that you won’t deliver a mission critical feature, because you had to stop all your software engineering activities, caused by your security department having this unreasonable request of focusing solely on security for a next couple of weeks. Customers care about security, but not that much, to let you lag on service delivery.

Build secure SDLC

Security is more cost-effective if you start working on it at the earliest phase of SDLC.

Old tried and true, isn’t true anymore. The common practice of building a product and throwing it at a security team doesn’t scale anymore. Given how much code we produce on daily basis, it’s increasingly more expensive to not instill security in early phases of SDLC. At current pace we can’t afford waiting will last phase of SDLC, because a need for potential refactor of two weeks of code would come with dramatic costs.

Securing the whole workflow drives very tangible long-term improvements, because to me it’s less about catching issues earlier than it is about education that ultimately is something we’re looking for. Developers who’re constantly exposed to security work, will memorize more and more of it, keeping safety in back of their heads and allowing them to fix the issues even faster.

We don’t want to see same mistakes over and over again, and unfortunately that’s something I still see at most companies all over the globe. Although the software engineering world moved forward a lot, security practices are still holding it all back and we haven’t globally addressed the basic issues that are so trivial to be remediated. It’s all about mindset and it’s all about moving the responsibility to the left and then making sure everyone is capable of taking ownerships of it.

 While I get it that approach of black box pentesting was somewhat practical in the past, - been there and done that - nowadays most innovative software is too complex for security teams to secure the product in just few days before it hits production. There must be a whole lot of things done around it, which we’ll discuss in DevSecOps chapter later.

Surely there are small software houses with senior, security-savvy engineers where it’s practical to build a tiny product and then deliver it to security testers, because they cared about security while writing their code. But during my whole career having had worked with thousands of engineers from dozens of companies, I can name only a handful of such senior level of security-savviness so hoping that you have people who are somewhat competent in security isn’t the smartest thing to do.

Actually, hope rarely is a good strategy for anything in life. It’s good to have, but it’ll take you only this far.

However, if what you’re doing works for you, your company and your customers, then keep doing it. I want to emphasize it once again, that I’m sharing yet another perspective that if you feel a need to, you may want to try out. So while I’m advocating an approach of injecting security into whole software development life cycle, I realize that it is not a silver bullet and it may be too expensive for you at the moment. Yet still, I believe that 1% is much better than 0, so trying something is better than sitting stale and missing the right point when you were supposed to take action.

My recommendation always is to get involved in product design phase and keep an eye on the product throughout the whole development process. 

It's all about cloud and dirt. About having the high level vision and long-term roadmap as well as doing what needs to be done to help you organisation achieve the goals.