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.
