In the cybersecurity industry, the focus of every managed security service provider is to reduce the time to detect a breach and remediate it. According to the last McAfee Incident Response survey, only 29% of respondents report a remediation time of two to seven days while the others report much larger delays. When we ask them what could be the biggest impediment to incident response efforts, 65% of the respondents mention the lack of skilled and well-managed personnel.
There are a ton of hipster management methods around that promise great results in terms of motivation and performance. I tried some. There are also good certification businesses behind all that stuff. At the end of the day, while you can still extract a lot of interesting things from them, you can’t learn how to deal with social complexity using a locked framework. The good news is that you can find all the answers you need just by questioning yourself and by honestly taking care of the people and the system around you.
I identified five interesting management practices and tricks that helped us, at Kudelski Security, handling social complexity while providing high end results. Most of them are inspired by agile methodologies like Scrum, Management 3.0, Systemic Organizations, plus common sense. The purpose of this article is to share those practices, encourage you to test them, and get your feedback on the topic.
Hire the right people
We mentioned it’s hard to find skilled experts around. Our field is in perpetual evolution and the needed skill set also. We all know the hiring process is critical and mistakes in this process could cost you your business. So, what do you want to do to reduce this risk? From my point of view, as soon as a candidate is truly interested by your business, has the basic required knowledge, and, most important, has a positive energy with a can-do attitude that will fit your team in place in terms of personality, you could be in front of your future ideal colleague. The other points are just bonuses.
Also, don’t let toxic players stay too long in your team if they don’t want to play the game in place. Not everyone can fit your culture and as a leader it’s your role to take this kind of decision to preserve the people and the system around you.
Choose your framework
You hired the good people, you now want to find a good framework for your team. Individuals rarely auto-organize themselves without some guidelines and there is a high chance they won’t feel satisfied in a non-structured environment. It may sound weird to say that, but I have seen many places without clear project methodology or guidance and you don’t want that if you are looking for results and happiness. On the other hand, I would recommend choosing the method that suits your team and context and stick to it with firm discipline.
Discipline doesn’t mean your framework will not evolve or that it will constrain people. You just want to put in place a set of rules with a clear direction and objectives and let your team organize themselves inside this framework. The process in place should be lightweight. We just want it to serve our people and our system, not to slow them down. As a product owner working with developers in a fast-paced environment, we choose to use Scrum with two week sprints as our core methodology. It’s adapted to our context, lightweight and effective while ensuring large autonomy for team members.
Measure your system and adapt it
Scrum is also great as you can play with it and add some good practices around the method to make it fit your needs and reality. You can iteratively build with your team a strong definition of done (DoD) to therefore ensure a better estimation process while boosting your code quality, adding extreme programming practices (XP). You can improve everything, and you want to do it. Just keep in mind that the improvements should be not too frequent, they should be motivated by measured facts or needs, and don’t forget that you should be disciplined and stick to your process when you find something that works. In the Scrum case we are lucky, you can inspect everything using KPIs like the burndown chart, the velocity, or the release burndown to collect facts. We even have a cute, useful, and funny tool called TeamMood to measure our team happiness!
Collaborate massively
Your company is generally not only composed by your team. You are working in a living system with real human individuals, not resources on a dashboard. It’s great to try to know them better and understand what they are doing. With a better global social understanding of your system and good knowledge sharing, you will be able to reduce the unknown that naturally creates a silo effect and a propensity to conflicts while generating great collaboration opportunities. You will also reduce the risk of bad choices if you can involve in your decision some external selected people that will bring a fresh view on your ideas.
At Kudelski Security, we are always trying to reduce the gap between people and gain benefit from their skills and experiences while being more efficient. A good example of that is the DevOps culture we have between our development and infrastructure teams. We really want to act as an entity integrated in a single methodological framework and we are close to achieve this goal which is a real challenge.
Embrace leadership
I won’t reinvent the wheel here as everything has already been said about leadership. Still, I assume that it must be remembered that you cannot act only as a manager. You must be a leader for your team and for me that mainly means being authentic and available for them. You trust your colleague, so you give them responsibilities. You also take care of always providing the “Why” while letting them manage their planning and work style on their own. Finally, you’ll make sure they can sometimes work on their own suggested topics and as soon as possible, free them from the corporate routine by sharing a drink or any other cool outside team building event.
Sometimes our industry tends to forget that people are still making a huge difference in our field. We also need to consider the fact that skills and performance can only emerge in an appropriate environment. Based on my experience, a happy and motivated team is always more efficient than a simple suite of super skilled experts. They will also stay longer in the company. As a CISO who wants to reduce time to remediation or as a leader who wants to succeed in his business, you should take the chance to think about social complexity and happiness at work as a top priority.
Are you on the “Team of No”? How do you know? Do you often get pulled into a project late in the process, where security wasn’t even considered or notified until 3 days before the ‘go live’ date? Do you have business executives agreeing to any and all security policy exceptions without even understanding the full details? Do you often find the business or IT going around security processes that you control? If so, you might just be on the Team of No!
At many corporations across the globe, the security department is often seen as a hindrance to the business, a necessary evil who has these strict security policies written so no one can do their job. Sadly, many Cyber Security Leaders take a risk avoidance approach where they themselves feel they ‘own’ cybersecurity risks for the organization, who must protect the business from itself. Making it difficult for the business to adapt quick enough to disruptive innovations, among others, is a key reason why many security leaders don’t get invited to the C-Suite table.
One of the key elements of a highly effective security organization is to establish a security risk committee (or several), with executive participation from key departments and with leaders across the business who truly own the risk. Often times, standardizing on a consistent risk assessment methodology across the company, and bringing key risks to this security risk committee will allow the security executive to share the burden of balancing risk with business objectives. When done effectively, the security risk committee will often drive appropriate behaviors within the various parts of the organization, improving the support for security processes and practices.
One of the key outcomes of a security risk committee is to empower the risk committee members through education and collaboration on cyber security. It is worth reiterating that the security organization doesn’t own cybersecurity risk, rather, it enables the information owners to better understand and manage the risk. Additionally, the risk committee needs to understand that the security organization cannot prevent data breaches, however, it helps to protect information, monitoring for attacks and anomalies, and responding quickly when an incident does occur.
While a security risk committee is now common practice, it is also important for you as a security leader, and for the security department, to find a way to “Get to Yes”. This doesn’t mean that you say yes to everything that comes your way, but instead, collaborate with the business to come up with alternatives which ultimately satisfy the business need that aligns to the risk appetite of the organization.
Here are a few recommendations to be a better business partner, and get to yes:
Understand the other person’s position, and their needs
If an ask is too risky, start with ‘why’, and share details in relation to the business impact
Separate the people from the problem
Focus on interests, not positions
Be less rigid, and more agile
Work together to create options that will satisfy both parties
Get out of your office, and be visible
As you set the security strategy for the organization and do your best to manage risk, keep in mind that 99 percent of your success as a leader depends on relationships with people from other parts of the business.
Our second CISO Fresh Thinking webinar, “Getting to Yes C-Suite Strategies for the CISO,” explores this and other key attributes in greater depth.
You can download the webinar now to hear Don Kleoppel, CISO at Cerner, discuss with Kudelski Security’s John Hellickson, Managing Director of Strategy & Governance Advisory Services, how this particular shift in mindset can help you enable the business to achieve its strategic objectives.
October is Cybersecurity Awareness Month, a time traditionally focused on empowering individuals and organizations to adopt more safer practices online. But October should also provide a moment for honest reflection among the professional security community about what is – and isn’t – working in our security arsenals. The security executive role is evolving. Kudelski Security’s new suite of CxO Performance Solutions provides new tools, programs and methodologies for the security leader in your organization. Find out more about CxO Performance Solutions here.
The competitive and often opaque talk selection process of infosec conferences can be confusing and discouraging. If you submit a talk—an abstract plus a longer description and a biography—and your talk gets rejected, most of the time you won’t get any useful comment from the board justifying their decision. Submitters then often perceive the process as arbitrary, driven by hype, favoritism, and egos. This isn’t always wrong, but not all conferences look like cosplay-free comic cons. Conference organizers should be given some credit for trying to maintain a reasonable technical level while at the same time covering a wide range of topics and having broader-than-deep talks to get less experienced attendees excited about this or that topic.
To put the odds in your favor when submitting a talk, it helps to follow advice such as these by Enno Rey, Sean Metcalf, or Nathan Hamiel. There’s lot of experience speaking here, yet I’d like to add my two satoshis from a cryptographer’s perspective. I’ve been sitting in many program committees of academic conferences, but only in a handful of infosec conferences committees, which turned out to be quite a different game. My point of view is therefore more on the submitter’s side, after having talked at a bunch of high-profile cons such as Black Hat, Defcon, BSides, CCC, Shmoocon, Troopers, SyScan, or Infiltrate. I haven’t counted my ratio acceptance/submissions, but my submissions have rarely got rejected. One reason is obviously that there’s more demand than there’s offer for serious crypto talks. But I think I’ve also learnt how to prepare submissions that don’t suck and increased my chances of getting in.
As a submitter, your job consists in two things:
Do great work, be it pure research, survey of a topic, or opinions.
Describe it convincingly in your submission.
It’s worth mentioning that 1. should be done before 2., and 1. should not be (only) motivated by 2.
Given these two dimensions, and to simplify a lot, there are four classes of submissions:
Great work + convincing description: Ideal case, likely to be accepted.
Great work + unconvincing description: May be accepted, if reviewers know the topic well enough to go past the poor description.
Poor work + convincing description: May be accepted, alas, if reviewers don’t know the topic well and you BS well enough to fool them.
Poor work + unconvincing description: Likely to be rejected, and deserved.
Of course who you are or who you work for will also weigh in the selection process, but you can’t do much about it. So let’s focus on 1. and 2.
1. Do great work
Whatever your work, you should bring original, non-shallow thoughts to the table. New is better than non-new, breakthrough is better than incremental. But this isn’t sufficient. Your work should also be useful to your audience, and this helps if it addresses a problem that people have, now. In other words, your submission should be timely.
But reviewers will often struggle to judge of the quality of a work. They often have to use heuristics, and will typically assess the speaker’s expertise: Have you published some work that demonstrate the extent of your expertise? Have you previously published in well-regarded venues? And so on. This doesn’t (and shouldn’t) imply that veteran researchers get a free pass for weak submissions, but that, justifiably, the barrier to entry for them is lower.
Also keep in mind that “great” may not have the same meaning to you than it will have to the review board. If you’re a cryptographer, for example, you may think that your new multidifferential attack technique applied to break 9 rounds of AES in only 2^125 complexity is great. But people at the conference won’t care, sorry.
2. Describe it convincingly
Your submission, namely an abstract and whatever else is asked for, shouldn’t sound like it’s been written by an idiot. Clear writing is clear thinking. Be concise. Structure your description in different parts with logical connections. Read Zinsser. Provide the details that will convince reviewers—and later participants—that you know what you’re talking about, but don’t get caught up in irrelevant details. Try to make the reviewers’ lives easier.
In con submissions as in many other endeavors, trying too hard is counterproductive: Don’t exaggerate your findings nor their impact. Be careful with superlatives, jokes, and words like “cyber” or “pwnage”; you’ll sound immature. In your submission, don’t promise what you’re not sure to be able to deliver. And don’t BS, it harms everyone.
Talks are better with demos, but only good demos. A good live demo is better than a good screencast demo, but it’s also harder. Depending on what you’re demoing, the choice between live and screencast may be obvious. In any case, a submission will sound more convincing if you say “I’ll demo X and Y and Z” than if you just say “there’ll be a demo”.
Closing remarks
After receiving good news from the conference, make sure to deliver a good talk, it will increase your chances with the next submission. If you get the reputation of a good speaker then review boards are more likely to excuse shortcoming in your next submission.
Don’t think that having talks accepted means that you’re a genius. Actually, most of the best people don’t talk at conferences, and don’t care. See the scientific diagram below.
While you might think that your reputation precedes you, different conferences have different expectations and, most importantly, different audiences. Always work hard on the submission and don’t think that your name plus a rushed abstract will suffice. Of course you will feel rejected when your submission gets rejected. But complaining on Twitter is, at best, a nuisance, at worst counterproductive towards your next submission. Your talk, while brilliant, might quite simply not be appropriate for the intended audience.
Thanks to Arrigo Triulzi and Halvar Flake for their comments on a draft of this post.
Kudelski Security Vice President of Global Advisory Services Mark Carney and Tony Spinelli, COO/President of Cyberdivision at Fractal Industries are back with another installment of ModernCISO. This time they’re in Dallas, Texas. Tony and Mark will be discussing three pieces of advice on how to be a successful CISO.
Welcome to the debut of our brand new Modern CISO web series. This series is a platform for security leaders to gain insights from their industry peers on cyber security topics. Presented by Mark Carney, VP of Global Advisory Services at Kudelski Security and featuring Tony Spinelli, former CISO from Capital One and current Chief Operating Officer of Fractal Industries Inc., this installment revolves around cyber board communication and metrics.
Software development methodologies have seen change significantly over the last 10 years. In many companies Agile has outpaced waterfall as the development model of choice. In addition, development teams may now have their own infrastructure operations working inside the development team.
Driven by the adoption of agile, DevOps refers to a set of practices that emphasize the collaboration and communication of both software developers and IT/Infrastructure professionals while automating the process of rapid, reliable software delivery and infrastructure changes [1]. The transition to agile processes may not be consistently applied to an entire organization. Traditional support functions such as IT, of which CISO’s are often organizationally aligned, may not have changed their own processes to keep up with the changing demands of these internal customers. So where does traditional CISO guidance and long-term security strategy fit into this agile world of continuous development and deployment via infrastructure as code? CISO’s face the challenge of adapting to this changing environment or risk being left behind and unable to assess the security of their company’s software.
The OWASP foundation states that the “CISO can choose to achieve security goals through three main ways; People, Process and Technology. Focusing on one or two of them can leave the organization vulnerable” [2]. Why is it then that developers, DevOps practitioners and product owners in many organizations have little interaction with the CISO and their teams? Is it because developers perceive security teams as being slow or a block to progress? It’s certainly possible: a recent DevOps industry survey found that 65% of security respondents are in agreement that security is seen as an inhibitor to DevOps agility [3].
CISO’s and their teams can help mitigate that perception. A recent Puppet State of DevOps report says that high performing teams spend less time fixing security issues because they address security at every stage of the development process instead of trying to retrofit security at the end. In fact adding InfoSec earlier in the development process is one of the top 5 priorities that surveyed DevOps teams wish to focus on [4].
So this would appear to be a perfect time for CISO’s to collaboratively engage with their DevOps colleagues.
What are some simple steps that CISO’s can take to increase effective interaction and drive this culture of what is recently being referred to as DevSecOps?
Enable DevOps use of Cloud Services. In many companies, especially where CISO’s are part of the IT organization, they may have noticed a correlation with the adoption of a DevOps culture and the increased use of cloud services. Often DevOps infrastructure groups will prefer to integrate with feature rich AWS or other cloud based service providers rather than internally developed or administered IT platforms. Rather than simply hoping that developers are not putting the company’s data at risk on unknown test and production cloud based infrastructure, CISO’s should publish clear and practical standards and guidelines about which cloud providers can be used, how and where data should be processed to satisfy regulations such as GDPR, whether source code can be stored in the cloud, and what steps need to be taken to ensure security and compliance. Keep these documents simple, up to date and ask for input from DevOps teams when drafting to ensure current usage is established.
Embrace Continuous Integration and Delivery. Back when Waterfall was the only game in town, it was easy to insert manual security checks into the master development schedule. Perhaps one after Alpha, another around Beta and maybe a PenTest. Tools didn’t need to integrate or even be connected in any way to the overall development tool chain. Someone could be assigned to run a scan and an impressive report could be generated so the appropriate completion checkbox could be marked on a master project checklist. With the ability to do multiple builds and deployments per day based on a feature backlog, there needs to be a reliance on integrated lightweight security tools that are seamless in the overall process and do not cause bottlenecks. The good news for CISO’s is that all of this process is scripted and automated and leaves very tangible evidence in the form of event logs and owners. If this automation is correctly enabled, DevOps makes it easier to have auditable recorded segregation of roles between development and production.
Show me the Money. Depending on your organization and if specific tools are being recommended for development teams to use, it’s worth keeping in mind that many of these can run into high six figure amounts. In many cases, these are not budgeted by development leaders and difficult choices may need to be made to balance InfoSec compliance versus what developers are measured on, namely on-time, quality product delivery. Sometimes cheap or free alternative tools must be used instead of expensive, comprehensive alternatives because of cost. These cheaper tools may not mitigate vulnerabilities as well as better, more expensive tools. If CISO’s can bring some money to the table, it can often make preferred solutions for risk mitigation a lot more palatable.
Get Involved. Depending on how Agile is being implemented in your company, there will usually be an event, or Sprint Demo, every couple of weeks. This is a chance for all interested stakeholders to see what has been completed in the previous sprint and to offer input or guidance. This is a perfect opportunity for a CISO or his/her team to get real-time insight into what is happening and to offer leadership on what might be missing from a security and compliance point of view. Many teams even record their Sprint Demo’s and they can be viewed offline – ask your development teams to see how this is handled where you work.
Become the Product Owner’s Friend. In Agile development, unless a feature or requirement is in the product backlog it will not be acted upon. A CISO can work with an agile product owner who owns the master backlog to explain the importance of security, and work collaboratively to add security specific epics to the master product backlogs. The CISO can also advise on what criteria must be met for final acceptance.
Command an Army of Champions! A neat idea I’ve seen in many companies is for there to be a developer assigned the role of security champion in each of the main development teams. By involving these champions, it allows a CISO to have a more focused conversation around the challenges, a chance to solicit input and an opportunity to identify teams that could pilot new approaches and drive change from the bottom up.
I hope this blog has given CISO’s some ideas about how to work collaboratively with development and infrastructure operations teams. I’d welcome your feedback and comments about what has worked well for you and what you might try differently to keep your development organizations secure.
