Vulnerability management is still a tough thing to rally support for and everyone loves a good story, so today I figured I’ll just combine both!
Once upon a time, a company took all of their employees camping. These employees saw all of the signs posted about the campground warning that there might be bears. They understood the warnings, but they hadn’t brought any bear safe food containers with them. Deciding to shrug off the warnings and go to bed, figuring bear attacks happen to other campers, they all turned in for the night, with food packed neatly inside their tents. That night, a hungry bear came through and ate all of their food as well as all of the employees, save one, who lived to tell about it to the media.
This is how most companies approach vulnerability management. They purchase a network vulnerability scanner, which identifies the threat, and they send out reports. These reports are circulated so everyone is well aware the company has vulnerabilities in the environment. Whether the threat be a bear or an outdated version of MS SQL, this activity is one and the same – it’s simple vulnerability identification. We are screaming to our company, “YOU HAVE BEARS!”
Ok, great. Bears. We have them. Now what? In order to avoid being eaten by bears, we can’t stop there. Flyers at the campground are great, but these campers don’t know how to combat the threat of bears. They’ve never been camping and they don’t understand proper food storage techniques. We must itemise the actions for creating a bear safe campground and delegate these tasks to those who need to act them out. We must also summarise the tasks and give our leadership a better idea of what the overall labour and material costs will be, so they can appropriate allocate resources.
In this case, our reporting must take two paths. First, we tell our leaders that we’re going to need three people, a dozen bear safe food canisters, and some rope. This is the same as realising that patching Java breaks a user’s ability to use a critical application, so remediation will actually require coordination between application developers, server administration teams, and desktop administration teams. We present not only the problem (bears) and the risk (being eaten by bears), but a full remediation plan for mitigating this threat (bear safe containers hung from trees). As the people legally responsible for reporting the breach (eaten campers) to media and regulatory agencies as well as paying any fines related to the breach (death benefits for the poor people eaten by bears), our leaders must understand their responsibility to the organisation and the risk that they are incurring if they ignore your guidance.
With leadership support, we now have money to buy our bear safe containers and rope, along with the personnel we’ll need to carry out our plan. Now we can assign one individual to stuff all the food into the containers and have the other two work together hanging the containers from the trees. Delegation is the key to vulnerability management, but we can’t delegate without leadership support, so we must work both paths in tandem.
By working these two paths of reporting instead of posting generic warning signs around our campgrounds, we ensure that everyone is not only aware that there are bears about, but they are appropriately equipped to mitigate the risk. By understanding the risk as well as the tasks required to mitigate it, we can orchestrate a successful bear proofing campaign across our organisation and no one will get eaten by bears.
Sometimes, you reach a point where when you look back, you shake your head and wonder how it ever was that you got there. That’s a bit how I feel about the security industry. It took off like a bat out of hell, full of a bunch of misfit kids trying to do good and satisfy their inner curiosities, took a turn at federal backing through regulations, and got lost in the woods of bureaucracy. Meanwhile, we were all trying to convince ourselves that we hadn’t sold out – we’d bought in, and we were making a difference, but that difference has to be glamorous and sexy.
I hate to break it to everyone, but security isn’t sexy. Sure, the very visible pentesting and malware research seems sexy on the surface, but for every one of them, there’s a thousand more fighting the good fight on the front lines of battle – inside the organizations being targeted for breach. And yet somehow, we’ve left those valiant soldiers with the idea that if they do their time in the trenches, they too can grow up to be posterchildren for the revolution on the offensive side. It is a prize to be obtained, while the true heroes are unappreciated and unrewarded.
This has led us to our typical career progression in security. We have our fresh little newblets start out in a SOC rotation, slaving away at odd hours, mindlessly watching for alerts to pop up. When they get a little more seasoned, we move them into analyst roles, pouring over scan results and trying to predict where an attack may be likely. Finally, when they have a good idea of where attacks are possible, we let them try their hand at the offensive side. It seems logical, right?
Except that it’s not. Look at the recent breaches – what is the one thing we’re consistently hearing? Alerts were ignored. Target and Neiman Marcus both have shown that some of those fresh little newblets ignored critical alerts. As a former fresh little newblet in a SOC rotation, I recall oh so clearly what happened the first time I saw one of these alerts on my shift.
Hey, what’s this mean?
Oh, that’s noise. We see those all the time. Just hit “ignore all”.
As simple as that, I could have become the person on the end of the finger pointing. With little training, little supervision, and little sleep, our most critical frontline roles are staffed by those least able to recognize a legitimate attack. Even with a few years experience, security operations folks learn only to recognize regular patterns and not to detect anomalies.
Personally, I think we’re doing it all backwards. Taking our newblets under our wings, we should teach them to think like hackers as penetration testers. Only then can they progress into understanding how to remediate vulnerabilities and detect attacks in progress from the defensive side. Instead of asking them to prove themselves doing the dirty work that we don’t want to touch, we should ensure our SOCs are staffed with the appropriate seniority and expertise to detect these real-time threats.
How can we bring sexy back to the trenches? Maybe if we get a new movie with someone as hot as Trinity using Snort instead of Nmap, we’ll finally attract the highly skilled talent we so desperately need. Until then, it’s up to the business side to ensure these positions are sufficiently attractive by demanding expertise and providing appropriate compensation. As long as the salaries for operations remain firmly entreched in “entry level”, we will continue to see cases like this where alerts are ignored and dismissed without a full understanding of the impact.
One of the most frustrating parts of external penetration testing was coming back the next year and finding the same vulnerabilities. When you look at the remediation plan you gave them, it looks like it took nine months just to figure out who was responsible for each of the problems. The other three months seem to have been spent on rationalizing why a critical vulnerability shouldn’t be resolved until after the next big upgrade, with a few minor patches being applied just to get the numbers to drop. Yet somehow, your client is astounded when you have domain admin creds by noon on the first day.
The worst part is that this isn’t limited to the findings of external consultants. Year after year, I come into organizations who have embraced the need for Vulnerability Management. SCAN ALL THE THINGS! GATHER ALL THE DATA! The metrics show you must be succeeding, because 100% of your enterprise is being scanned every month and you have an independent penetration test performed once a year. We lose sight of the “Management” part of Vulnerability Management and stop at Vulnerability Identification.
Knowing might be half the battle, but the war is won with actions. A truly successful Vulnerability Management program must have a function in place to see vulnerabilities through to remediation. Of course, the actual remediation activities almost always take place within various IT engineering teams, which means that in order to succeed, you have to drive cross-functional work streams. Taking accountability for overall security posture while simultaneously farming it out to individual business units is difficult, but it’s not impossible. Here are some simple steps to drive and measure a successful Vulnerability Management program.
1. Know how your organization is structured.
Are functional IT groups responsible for all systems by platform? Does each application have an assigned IT owner? You have to know who is responsible for which layer of the stack before you can start delegating.
For internal vulnerability management, set up reporting within your scanner to do some of this delegation for you. If you know that an IP block corresponds with a specific application, assign these addresses to logical groups. The more information you can assign statically, the less work you’ll have down the line.
2. Notify the proper teams.
If you’ve discovered a XSRF vulnerability within a web page, you’re unlikely to make much traction with the Unix team that maintains their servers. Within your reporting, start by sorting results by server platform. Then, while performing analysis on the results and eliminating false positives or allowable configuration items, sort the results further by the teams you previously identified.
Ultimately, you should have several reports tailored for each specific group. For example, all of the Windows items pertaining to patching and configuration may be consolidated into a single report for that team, but this report wouldn’t have database or application vulnerabilities. The application layer vulnerabilities would be similarly grouped according to which developers were responsible for each application. If applications share development teams, group those together for the fastest response.
3. Hold teams accountable.
A vulnerability management policy is essential to your success here, along with the organizational divisions you identified earlier. If your policy on critical security vulnerabilities states remediation should occur within 30 days, run a report on critical vulnerabilities over 30 days old, grouped by division of accountability. Do the same for all vulnerabilities, by division, older than 30, 60, 90, 180, and 365 days.
Use these in report-outs to leadership to show where teams are consistently failing to meet remediation obligations. While the business owner might not understand what each of these vulnerabilities means individually, they must be held accountable for the risks they are introducing.
4. Work on the bigger picture.
Delegating responsibility for individual vulnerabilities still only resolves the immediate problem. Go back and look at all vulnerabilities for the month and identify trends. Are you seeing that OS patches are being applied, but third-party applications are being missed? Perhaps there is a single cluster of systems that are consistently being missed in patching or configuration updates. Maybe there has been a high number of SQL injection flaws in applications. These are all symptoms of a bigger problem.
Work with divisional teams to reduce vulnerabilities proactively. Evangelize the need for baseline configurations for systems and standard patch windows. Train developers on preventing and identifying security errors earlier in the development lifecycle. While “total number of vulnerabilities” type metrics are generally bad for showing an improved security posture due to the unpredictable number of new vulnerabilities, you may see improvement in “vulnerabilities by type” through earlier security involvement.
5. Follow through with support.
Last but certainly not least, make sure your business partners know that you’re there to help them. Help find workarounds and mitigations for critical vulnerabilities that don’t have a patch available. Show developers how to reproduce an attack so that they can test their fix. Ensure those responsible for fixing the vulnerability understand how an attack would be executed, as they may have a workaround that resolves the problem when the proposed solution impedes business operations. Be a partner to your business units and they will work with you to drive security throughout the organization.
One of the interesting things about the infosec community is how lopsided the skill sets tend to be. Most of the seriously brilliant creative people I know are from this community. Try to get any of these folks to add some soft business skills to their repertoire, though, and they shriek and run like vampires from sunlight. For everyone with a healthy fear of leadership responsibilities, here is a simple primer to translate what you already know into “business-ese”.
1. Define the scope and stick to it. “Scope creep” is not your friend. Projects must have a finite point where they are finished and rolled into production. Even if it’s just one little feature request, you need to evaluate how it will impact your timelines and the importance of the feature to the business before deciding whether to include the feature into your current project or save it for the next release.
2. Break it down. Even where it seems obvious, state the objectives that define the scope of the project. Be sure your objectives are SMART (Specific Measureable Achievable Realistic Time-bound). Then go a step further and define the individual tasks which make up each of these objectives. While the tasks may evolve during the course of the project, especially during design, it is important to be able to track progress within these objectives.
3. Be realistic about timelines. Yes, if you work for 16 hours non-stop, you can totally get that out tomorrow. That’s not realistic. You’re probably working on at least four other projects, half your day is tied up in meetings, and someone is going to do a drive-by with an urgent question that “you can probably answer in five minutes”, but actually takes the rest of your afternoon. If you’re lucky, you’ll get two hours of actual work time in your day. So, if you think it will take you a day or two, estimate a week. If you think it’s a week, you’re probably looking at a month. Account for all of the things that you don’t want to have happen, but inevitably will – Exchange will go down, your browser will crash, and that last code change won’t commit and will disappear into the ether. Underpromise and overdeliver.
4. Know your strengths… and those of everyone else on the project. This one goes double for infosec folks. While you understand the nuances of each area of infrastructure, you’re not an expert in them. Leverage the skills and experiences of those assigned to the project to create a solution that is both secure and meets the needs of the business in the most efficient way. Rather than trying to design solutions with your limited understanding of the technologies available, explain your concerns with the current proposal, ask for recommendations, then work with the infrastructure teams to create threat models of each proposed solution. Creating a collaborative environment and orchestrating contributions from everyone on the team is one of the most critical pieces in leading a successful project.
5. A project without a plan is not a project. This is where the rubber meets the road. Having identified the scope and the action items required to achieve those objectives, reasonable timelines, and the individuals best able to complete each task, it’s time to put that all into a plan. Identify which tasks can be performed concurrently and lay out timelines for each task. While things happen and timelines shift, it’s impossible to gauge progress without a baseline. Having this plan vetted and approved by each team member ensures that you will be able to fall back on the plan when you need to enforce timelines or receive deliverables.
6. A meeting without an agenda is not a meeting. Much like a project plan, your meeting agendas are your key to staying on track. It is important to foster collaboration and allow for the free flow of ideas, but it is equally important to ensure outstanding issues are addressed, decisions are made, and progress is tracked. To go into a meeting without an agenda is to set yourself up for an hour of segues without resolution. Know what you’re trying to accomplish and ensure the rest of the team understands these goals, too.
7. When in doubt, over-communicate. You (and your leadership) can never know too much about your project. You should always be secure in your understanding of where the project is at any given time and be able to communicate that to leadership. Constant communication with the team ensures hurdles are identified early and appropriate resources are allocated before the hurdle becomes a roadblock. This is the most time consuming part of project management and one that is all too often overlooked. Being transparent and ensuring everyone is in the loop facilitates the collaborative environment that breeds success.
8. Wrap it up. As discussed in the first point – a project ends. When you have accomplished the objectives in your scope and everything is nicely deployed, it’s time to hand this off and prepare for the next challenge. By tracking timelines, creating deliverables at each step, and documenting progress, you should have a nice packet prepared for turning over to the team which will be supporting this work moving forward. It feels a lot like reluctantly sending a child off to college, but you have to let it go before you can tackle your next challenge.
In security, we’re not only expected to be Jacks of all Trades, we need to maintain a high level of mastery in each area, as well. We must be able to design secure networks, provide system and database level hardening for all platforms, expertly guide developers in writing secure code, oversee incident response and disaster recovery, and even know about the physical locks and environmental controls.
It definitely takes a special kind of person to make it in this industry and most of us started out as hobbyists, before professional options even existed. We gladly take on these responsibilities, to the point of excluding other teams who specialize in each technology. As much as we love having our egos stroked, though, this trend is not sustainable and it doesn’t enable the success of the organization.
In today’s world, the primary function of security needs to be evangelism. By educating infrastructure specialists in security principles, we can leave the implementation details to people who have spent years specializing in their specific technologies. Like it or not, these administrators, engineers, and developers have far deeper knowledge in their areas of expertise than we could ever hope to gain, as they have dedicated their educational pursuits to one focused area, rather than trying to do it all. It is our job to enable the success of these experts, as we introduce security concepts and help to foster a passion for security in those best able to bring these concepts to life.
Conversely, infrastructure specialists need to start taking responsibility for understanding security concepts. Confidentiality, integrity, and availability affect every area of business. Given the tremendous impact of security breaches and the public attention this topic has received, it seems absurd that in many organizations, these specialists are not held accountable for this critical area of knowledge. By effectively evangelizing to leadership teams in our organizations, we can bring passion for security and set a new minimum bar for job requirements.
Imagine a world where security topics are considered a piece of knowledge as fundamental as the OSI model and are integrated into the core requirements for each infrastructure role. In this world, security teams would have a well-defined role of oversight, advisement, and evangelism, while working in harmony with infrastructure teams, rather than sitting in an isolated silo, only coming out every once in a while to tell someone, “NO!”. It’s not enough to shape our own world; we have to bring our message to the masses if we ever hope to get ahead of the fight.
One of the interview skills that is most often preached yet least often followed is this – Research the company before you walk in the door. Without understanding the organization, its products, and its values, it’s very difficult to explain why you would be the best person for a job within it. It is important to understand not only how you would fill the role, but very specifically, how you would fill the role at that company.
When I am interviewing candidates for security roles, I will often ask questions about what they think the biggest risks are to the organization. One candidate, coming from a role with an online gaming company, believed DDoS attacks would be the biggest concern, without realizing that as a brick and mortar retail business with no e-commerce, this type of attack would have very little impact on the organization beyond a minor PR hiccup. Another candidate, focusing on compliance risks, said that PCI compliance would be a concern, with SOX being a possible implication if we were publicly traded. Wait, what?! If you are interviewing with a well known Fortune 500 company, you should at least know whether or not they’re public traded!
Small details like this can have a large impact on how you would apply your role within the organization. After the interview, this information becomes even more vital to how you’re applying your resources. One thing I’ve learned very rapidly in this industry is that you can’t try to “boil the ocean”. In any medium to large organization, you could have small armies working at full utilization just trying to keep up with the day to day demands of trying to keep every system secure.
By understanding your organization’s core competencies and values, you can identify the risks which would have the biggest impact. If Internet-facing systems are offline, can your company still do business? Would it be noticed as a small hiccup in daily business, or would it negatively impact customer opinion? What critical data is being stored? Which of these would have the largest impact to the organization if it was breached? While it’s easy to see that retailers would likely be most affected by a breach to payment systems and health care organizations place most importance in the patient record, some companies are a little harder to pinpoint. Be sure to consider financial impact, legal repercussions, and PR implications.
Whether you’re trying to get your foot in the door or you’re looking to improve your current organization’s security strategies, it’s critical to understand the business drivers for your solutions. Our mission needs to be to improve the security posture while furthering the needs of the business. Sometimes, concessions will need to be made to ensure business can operate, even if it comes at a security risk. What is important is being able to identify that risk, fully understand its potential impact, and present a risk-based evaluation of whether that impact may outweigh the business impact. Once you can do that, your value to the organization will speak for itself!
Regulatory Compliance – Two simple words that make security practitioners around the world shudder in fear and disdain. Compliance is traditionally the realm of box-checking auditors who seek to undermine the foundation of security, by turning complex architecture decisions into nothing more than a checklist.All too often, we see it as a hurdle that must be overcome, rather than a tool that can help us in our security advocacy.
First, it is important to establish what compliance isn’t. Regardless of how technically granular requirements may become (I’m looking at you, PCI-DSS and NERC-CIP), it will never be a magic bullet. Meeting the bare minimum set forth by these standards will never mean you’re “secure”. Indeed, it is even possible to do very little to secure your environment while still meeting the letter of the law.
Compliance is a system of checks and balances. It is a way to ensure you understand where controls need to be applied in your environment and that you are validating their efficacy. While the act of audit may be a simple box-checking activity, the act of achieving compliance should be seen as validation that you are meeting the minimum bar – not a seal of exemplary performance.
In information security in particular, it can be very difficult to measure success. Long ago, I heard a statement that really sums up metrics in security:
In security, we have three metrics:
1. We haven’t been compromised.
2. … yet.
3. … that we know of.
Since it’s so difficult to measure what we do, it becomes similarly difficult to justify doing more. We are a cost center with very little obvious ROI. It’s very difficult to justify the expense of a major undertaking, like properly segmenting a network or investing in application security testing capabilities. Bring along requirements from PCI-DSS and HIPAA-HITECH, though, and you suddenly have justification to make these improvements – along with repercussions for ignoring them.
Compliance should never be a substitute for “doing it right”. However, if you build a secure environment, it will, by design, be compliant. Once you understand compliance frameworks, it’s easy to see that they all say the same things in different ways. They all require adherence to and evidence of basic security controls. A well-designed secure infrastructure will produce evidence to meet any defined security requirement without impacting overhead.
Time and again, I see organizations do the annual “compliance hustle”. With binders full of discrete (and often contradictory) policies, they spend months scrambling to collect evidence to fulfill each individual audit. It requires several full time resources just to manage each scramble, plus many hours of work on the infrastructure side to fulfill the evidence requests. In the end, remediation activities are identified for controls that are already in place, because they were built for one specific purpose and only deployed to that environment. It’s a redundant and reactionary loop that is difficult to break out of.
Instead, we should focus on letting organizational objectives, such as achieving compliance with one specific regulatory body, carry the initiative of building a singular compliance framework. Through careful mapping of requirements to controls, a one-time architecture effort can easily result in a self-sustaining compliance program which can be maintained and kept updated to the latest requirements through the efforts of a single individual. By using an established organizational initiative to support the financial outlay of the effort once, ROI can be clearly established after subsequent efforts can be maintained with little to no infrastructure resources.
DISCLAIMER: This was written a very long time ago. My feelings have changed, but I think it’s important we don’t just scrub away the things where we might have been coming from a different place in our journey, to acknowledge where we came from.
I will say that I have come to understand the importance of representation in the industry in creating a culture where young women feel welcomed. I also understand that representation can be a negative thing, when there’s so many blanket accusations being made about all men in the industry that it causes men to exclude women altogether rather than risk being cancelled over an innocent misstep. But mostly, I think that if I personally strive to exemplify the former, that will ultimately result in seeing less of the latter in my personal sphere of influence.
So, I will leave you with my hot take below, knowing that the internet is forever. For all the young women who may be coming up in my footsteps, I hope that you see this in the spirit of accountability and growth. All we can do is try to do a little better every day.
——————————————————————————————————–
Last summer, while presenting at GeekGirlCon on a “Secrets of the Female Hacker and Maker” panel, I had a question asked of me.
“How do you deal with the misogyny of the Information Security Field?”
Wow. What a loaded question! It’s one that I rolled over and over in my mind, especially in light of the attention that has been paid to the topic lately. With women alleging “Defcon is hell for women”, I think perhaps I have been in the wrong industry and attending the *other* giant hacker con in Vegas for the last decade and a half or so. I wondered how it is that I and so many other women can be so comfortable in an environment that others find irreparably hostile.
One of the things that drew me in to the hacker community (and, eventually, the infosec profession), was how easy it was to be accepted on nothing but your technical skills. People who I had initially met on BBS and IRC had no idea what I looked like or what bits were between my legs. When we finally met in person, the fact that I’d just developed an early Gig-E over copper NIC was far more intriguing a conversational topic than what I was wearing or who I was sleeping with. If you could throw down and hold your own (through skill and education), you were welcome. If you couldn’t, you were harassed mercilessly and deterred from returning.
Around the same time, a number of women who weren’t involved with the con for educational pursuits started showing up. I saw the term “scenewhore” thrown around, and threw it around myself. I had a hatred for these women for making us all look bad by trying to gain recognition by getting naked instead of sharing knowledge. I was outspoken against these women on forums, when they came around with nothing to offer but fashion advice and demanded respect and knowledge be handed to them just because they were female. I almost gave up when the “HaXXXor girls” made their appearance, until my community surprised me and laughed them right off the con floor (while chasing them down to get their bootleg DVD copies signed, of course).
There continue to be the typical signs of the “boys club” mentality. Underground parties continue to hire strippers. The big corporate sponsors continue to use booth babes and go-go dancers to hawk their wares. Are these things conducive to fostering a safe and welcoming environment for women? Probably not. Does it make these misguided men any less welcoming of a well-qualified woman in their ranks? The experiences of a number of prominent women in this community seem to say “no”.
So, to answer the question that was posed of me, I’d say, “I don’t.” I don’t deal with the misogyny. This requires some social interactions that have been called “manly” and “aggressive”, such as grabbing an errant hand and firmly informing its owner that his actions are unwelcome. It has required exchanging business cards while a half naked girl wriggles and writhes a few feet away. It has not, however, resulted in less respect or a lower paycheck than that of my peers.
Changing the “boys club” into a mixed-gender playground will take some time and these attitudes towards what is acceptable for down-time entertainment are slowly changing. One thing that will never change – if you have something to offer this community, you will be welcomed into it.
I have frequently declined participating in women’s panels or forums within this community because it is the antithesis of why I joined it in the first place. I don’t want to be recognized as one of the top female names in my industry. I want to be one of the top names in my industry, period. This is one of the few communities where I feel that is a genuinely achievable goal.
The women I view as mentors are the ones who are doing great things in the top roles of this field, rather than those who have made their name by calling attention to the differences that are supposed to be holding us back.
Interviews are scary. You’ve managed to get past the screening software and onto the hiring manager’s short list. You have a legitimate shot at the job you’re hoping for. Your fate lays in how well you can express yourself in a few short minutes. The secret to good interviews is having your story when you come to the table.
What is your absolute perfect ideal world dream job? Where do you see yourself in five years, ten years, or at the end of your career? Think hard about what it looks like. What sort of company are you working at? Do you own this company or is it an existing company? What sets this company apart from others? Who are your coworkers? What skills are you utilizing? Form a picture in your mind – or better yet, draw or collage a picture – that clearly illustrates this objective. This image is the cover photo of your career autobiography.
Now, look at your resume. This is the table of contents for your story. Each entry should reflect a few key points about how that role has brought you to where you currently are in your career. It should tell a story about why you chose the role and what skills you gained or improved. Picture the work you performed in each role and how that work is contributing to your cover photo. If there are no talking points you can glean from that experience which relate to your story, perhaps that chapter should be left on the cutting room floor. Be sure each chapter is a complete story, including both beginning and end, and make certain your intro addresses what has happened in the time since the end of the last chapter.
Once you are in your interview, it is time to tell your story. While you will be asked directed questions, each answer should easily relate to one of the chapters you have outlined. Technical questions, achievements, challenges, and aspirations can all be gleaned from the story outlined in your table of contents. Even the tough questions that seem like a trap are easily told within the structure of this story.
Here’s how to tackle the tough questions, using the story you have prepared for yourself:
Q: “Give me a summary of your background”
A: Rather than recite your table of contents, which they’ve already read, give the chapter overviews. Mention specifically what led you to each role and how it has led you towards your cover photo.
Q: “What is your greatest accomplishment?”
A: While these should already be mentioned in your table of contents, as they are the highlight of each chapter, it’s important to decide in advance which one will best illustrate the type of success you hope to show in this new chapter. Have a clear picture of what drew you to this position and what skills will likely be called upon. This is your opportunity to show that you have not only achieved things, but that you can already see yourself achieving things in this new position.
Q: “Describe a time where you overcame an obstacle.”
A: Every job is full of obstacles. The important part here is not to badmouth your previous company and coworkers in this response. Whether your obstacle was an unrealistic budget,difficult coworkers, or a stubborn bug that couldn’t be pinpointed, the soft skills learned through these obstacles are just as critical to your story as the technical skills. Recite the chapter in which you resolved conflict, applied creative solutions, and charged forward to victory. Be sure this relates to the soft skills in your cover photo. If the person in your cover photo is a leader or a member of a team, this chapter should end in the unity of that team – not in success gained at the expense of another.
Q: “Describe a situation when you failed and what you would have done differently.”
A: This one is really hard. As with any story, not every chapter will be positive and uplifting. No one likes to dwell on their mistakes and shortcomings, but it is important to show how you have looked back on this trials and learned from them. Regardless of how damaging the failure may have been, a deconstruction of the lessons learned shows that you are prepared to avoid these pitfalls in the future.
Q: “What is your greatest strength? What is your greatest weakness?”
A: Most of us have a pretty good idea of our strengths, but few of us can tell them in the context of our story. The flip side of this is that some of our personality traits can make it difficult for others to relate to us. By understanding our strengths and what motivates us, we can see how conflicts may arise when a subject isn’t presented in a way that works for us. I will rarely plug books or products, but the StrengthsFinder 2.0 book and online test were invaluable for seeing my strongest personality traits and how they contribute to my career.
Road to CISO 