The First 101 Days as a New CISO - A Chief Information Security Officer's Playbook Posted by Justin Fimlaid on May 29, 2014 at 10:00 AM If you are a new CISO or starting a new Security Leadership gig, your first few months on the job are critical to your ongoing success in your new role. In the first few months you'll be judged, tested by your organization and staff, and put on a "stage" to perform in front of your C-Level peers. The precedent you set and first impression in your first 101 days will dictate how your organization perceives you and whether your tenure is marked by overcoming early mis-perceptions or you get a "hall-pass" to do all the good things you were originally hired to do. This is the New CISO's Playbook and some initiatives that will help you be successful in the first 101 days in your new role. Days 1-10 Start to get your arms around your Information Security Program. As you would expect the first thing to start doing is taking an inventory of all the pieces of your Information Security Program. This includes direct and dotted line Information Security Staff and their responsibilities, what program capabilities are in place and if possible how mature those capabilities are, any available metrics on department performance. It's critical that you at least start to take cursory program-level inventory of services in your first week, because as you meet with other Business Unit leaders in the coming weeks you can start formulating a more robust and relevant Information Security Program and Strategy. Get to know colleagues. This is an important step in kindling great relationships. If you have been promoted into your role, this is a good opportunity to attempt to recover difficult working relationships from days past. If you are new to your Company, as you have these relationship building discussions it's important not to pass judgment on anything you hear since you might not know the political underpinnings of the information that's being shared. Use this time to build political capital by listening to your colleagues, displaying empathy, and most importantly gather their goals and objectives so you can help them be successful when you build your Information Security Roadmap and Strategy. Hold a Department Meeting. This is a must-do! Your team might be apprehensive about having new leadership and how your strategy and management style will affect their jobs. Give everyone a chance to talk and ask questions. Be sure to listen, express empathy, and advise that you are still gathering information and not ready to make any decisions. Most importantly this is a good opportunity to demonstrate everyone is on the same team with a common goal. Review Budget and Associated Metrics. In the course of understanding your Information Security Program also spend some time dissecting your budget breaking down Capital and Operating Expenditures. The question might come up in the next couple weeks about the financial footprint of the Information Security team. If a lot Security of Compliance spending has taken place before your arrival as CISO, the question might be asked if capital expenditures can be reduced. If you are building the Information Security function for the first time in the history of your company there might be less attention on spending as an initial capital spend is expected; however, it might be good to begin political posturing to appropriately set expectations if you think a lot of spending might be required. Also use this time to find a financial analyst to assist in budget formulation and help communicating a common definition your CFO understands. Days 11-20 Queue up an Information Security Assessment. At the beginning of your third week, queue up an independent Information Security Assessment. Depending on the purchasing requirements of your company coordination of the assessment could take a few weeks and scheduling an assessor can require a lead time. This should be an an assessment of your Information Security Program not just a Penetration Test or Vulnerability Assessment. Find a quality Information Security Assessor who can review your overall program posture using a framework such as ISO27001. You would be well served to find an seasoned Information Security assessor that can measure the ISO27001 controls with a business context so you can gain an accurate read on business risk and subsequently appropriately prioritize remediation plans. Hold One on One Meetings with your team. Begin to meet with members of your team. Start with your direct reports first before making your way through your organizational structure. If you're organization is so big you can not talk with everyone then definitely make some time to talk with front line Security Staff even it means skipping the middle management tiers. Your front line staff are the individuals who see issues and deal with problems, and as problems are escalated from the front lines up the organization structure the message will get filtered before reaching you--so for a candid view of the challenges your security organization faces, be sure to talk to or survey your front-line team. During these meetings with your team you can and should be building political capital and trust within your organization. Ask for informed fact based opinions, what the department risks are, and seek their opinion as to how risks can best be mitigated. You can also use these meetings to establish your approachability by actively soliciting their feedback. Begin to Understand what projects or initiatives will be active in 6 Months time. Time permitting in your busy third and fourth week, start to understand new company initiatives or projects that might be active in six months time. The idea is that these will be emerging projects and initiatives you will be dealing with once you are full orientated in your new position, and starting to gather a strategy will help you be purposeful in your first 101 days and ensure your success on those projects or initiatives. Starting this process now will help give you some context when you begin having one-on-one meetings but it will also give a glimpse as to what members of your team are already planning six months out, and how they are tracking risks associated with these initiatives. Day's 21-30 Prepare Steering Committee Materials. By this point you've been in your position for a few weeks, if you have a Security Steering Committee you should begin preparing materials and begin framing what the first meeting agenda should be. If you are inheriting an existing committee this can be a tricky proposition because it's critical you get the first meeting right and start off the relationship on the right foot, the complexity of this arrangement can be amplified if you have the wrong stakeholders involved in the meeting (i.e. the committee members aren't at the right level in the organization). If you find yourself in this position of dealing with a low-level Security Steering Committee, you should pause and critically evaluate whether you want to "start over" with the committee--politically speaking it might be easier to dissolve legacy committees and spend time amassing political capital to build new. If you find yourself in this position, this step of meeting with the Security Steering Committee comes much later in your first 101 days. If you are starting a new Security Steering Committee for the first time, in addition to framing the agenda and first meeting format you should also be considering and actively selling the position to committee members you would like to participate. Hold One on One Meetings with Business Leaders. Start meeting with peers and Business Unit Leaders. The relationships you begin to form here will be critical to your ongoing success. In addition to gaining the trust of your company's Business Leaders, you should also begin learning what their goals and objectives are. It's important to gather this information and ingest into your strategic plan and strategic roadmap. This information will help to ensure your Information Security goals and initiatives directly correlate to business objectives. During this meeting also gather their advice how the Security team can help. Begin participation in Information Security Projects. At this point you should have an inventory of active Information Security projects. Based on your emerging work load pick some of the most important and strategic security projects to participate in. As you participate, keep in mind your position and granted creditability that comes with being a CISO. If you participate too actively you may inadvertently take over the project and accidentally derail progress. Establish some personal guidelines for yourself as you operate in these meetings, focus on steering the project and adding value or suggestions that might improve the project. Otherwise be a mentally and physically present tie-breaker when collaboration ends in a stalemate, encourage and motivate the team, and at the end of the day your presence in the meeting will give creditability to the project. Day's 31-40 Review the Operational Security Budget. Hopefully you were able to obtain a good understanding of your budget in the first couple weeks (Day's 1-10). Now that you have a solid month under your belt, you should be able to start answering specific questions about your budget and how spending is improving the program. By now you should have also recruited a financial analyst to help with your budget and develop ROI metrics and start developing metrics to show how you are improving the fiscal posture of the Information Security Program. Establish a Program Vision. It's doubtful you'll have your full vision formalized by this point, but if you do it will help shape the conversations you are about to have in the coming weeks. Following your conversations with business leaders from the previous weeks, you should begin to have a picture of what success looks like and how to help your company deliver on strategic goals and initiatives. While your vision might not be formalized, you'll have plenty of time to firm up your goals in the coming months. Consider this step a prerequisite to developing an overall strategy for your Information Security Program. Take Inventory of the Security Team Skill Sets and Establish Development Plans. In talking with your team, holding one-on-one meetings, and observing performance of your team members collect an inventory of skills. This inventory should include technical and soft skills. Soft skills are a little harder to articulate and measure but there are tested frameworks such as Lominger that can help to measure soft skills. In the course of developing a staff development plan give some consideration as to what your employee wants in their career. Based on the career aspirations of the employee that will drive their skills development. In this role you should act as advisor and motivator, the act of developing a plan should be driven by the employee and they need to be invested in the process to feel motivation to improve. Under-performing employees or employees with a negative attitude can perpetuate bad feelings among the team--and you owe it to your top performers to fix this ASAP. Also, don't spend all your time on the under-performers, each team member should receive equal attention. This might be one of the most important tasks that you complete. Spend some time here and get this right. Begin your Information Security Assessment. This should an independent review of your Information Security posture. While you might be qualified to do the assessment yourself, you should resist the temptation to do so. There's an opportunity cost in doing the assessment yourself, and the opportunity cost is all the program and relationship development you should be doing instead of the assessment. Additionally, the independent lens of someone impartial and removed from the organization will help add to the creditability of any findings. During this assessment it's critical, as always, to partner with your independent Information Security Assessor and guide them to ensure you get the results and quality you are looking for. Since the assessor is more than likely new to the organization, helping them think in the right business and security context will help to ensure an accurate measure of risk. An information security assessment without business context is just a gap assessment not a risk assessment. A risk assessment is needed so you can begin to prioritize what remediation efforts to tackle first. Depending on your corporate purchasing processes a 31-40 day start time might be unrealistic, but this assessment should be performed as soon as possible. This is a prerequisite to formalizing your Information Security Program Strategy. Day's 41-50 Write or review the Information Security Charter. Ideally you want your charter approved by the CEO and Board of Directors, so it should be written at a high enough level that it encompasses all your mission and objectives but still provides enough detail that you can translate the charter into an operational plan. If your CEO and Board of Directors take interest in this document, it's worth taking the time to get it right the first time because each edit and change will need to be "re-approved" by the CEO and Board of Directors. Alternatively, many CISO's have their charter approved by their Security Steering Committee. If you are inheriting an existing Information Security Charter, this is good opportunity to review the Charter and make any changes or modifications you require. Appoint team leaders. By now you've been able to observe the performance of your team for the past couple months and hopefully you have some obvious stand-out leaders. Considering your Information Security Program strategy and direction you want to take the program, you need to start putting the right team in place to ensure delivery of that Strategy. Considering the strength of the leaders you select should drive the autonomy which you afford them. Junior leaders might need a little more structure with work plans and project reviews. More Senior Leaders will be able to work autonomously and help you coach and provide oversight to Junior Leaders. Be visible in established Security Projects. Whether you inherited a list of Security Projects or getting ready to kick-off your own, you should judiciously select a couple projects to participate in. This will help to ensure projects stay on track or help and existing stalled project get back on track. Plus, while ramping up in your new role this will allow to gain some credibility in your team and show you're there to help them be successful. You have be careful not to overstep your role and responsibility on the project because depending on your background and expertise you don't want to be perceived as taking over the project from your team. Also, your role on the project should be a consensus builder not a C-Level overriding vote. There will be times when you need to pull out your "CISO card" but that should be only in dire circumstances; your modus operandi should be using your excellent communication skills to get everyone on the same page and consensus within the teams. Day's 51-60 Review Budget for Second Month. Review your budget again and by now you might be seeing trends in your expenditures. You should have enough information by this point to start making informed decisions about top expenditures. Also, now that you've met with your team about development plans, there might be some members on your team which you can delegate budget monitoring responsibilities. Meet with Information Security Steering Committee or Board of Directors. If you operate with an Information Security Steering Committee then you have flexibility as to when this meeting is scheduled, because you drive the agenda and timing. Alternatively, if you have an opportunity to meet with the Board of Directors you have to work around their schedule and agenda. Depending on when the Board of Directors meeting falls on the calendar and how it aligns with your employment start date it might make sense to skip presenting at the first Board of Directors meeting and so your first impression with the Board of Directors is strong, fact based, and value-adding to the overall business strategy. Obtain approval for you Security Charter. In previous weeks you published a new charter or you edited an existing charter. Now it's time to get it approved. Based on the timing of when the approving body meets, Information Security Steering Committee or Board of Directors, will drive when and how this task is completed. Before requesting a formal approval of the Information Security Charter you should make sure you have buy-in from appropriate reviewers. This will help to grease the skids of the approving body to ensure a smooth approval process. Form Security Awareness team. This might be most overlooked task in most CISOs Information Security Playbook. It's fairly challenging to continually develop new and engaging Security Awareness ideas, content, and dissemination schemes. It's common for a CISO to tag their marketing department to develop creative content and fresh ideas for delivery. It is recommended you enlist any and all help you can get from creative marketing teams. Everyone on the Information Security team has a responsibility to take up the Security Awareness flag and take a turn disseminating a Security Awareness message. There's many avenues which this can be completed, but at a minimum everyone on the team should have an obligation to deliver training at least once a year. Day's 61-70 Formalize your Information Security Program Strategy. Four months to develop a strategy might seem like too long, but considering your prerequisites of developing your vision (figuring out how good you want your Information Security Program to be), and completing your Information Security Assessment (figuring out how good your Information Security Program is today) you'll need sometime to put all these data points together. Your strategy should ultimately be your roadmap to delivering you program. Some ingredients to a successful Information Security Roadmap and Strategy include: a maturity model for each competency you plan to develop in-house, consideration of how/if an Managed Security Service Provider (MSSP) helps you mature quicker for less money, fiscal capital costs to develop a competency and how the investment improves the maturity of the program, fiscal operational costs to develop a competency (headcount, etc) and how the investment in staff and operations improves the maturity of the program. It's important to remember Information Security is a Risk Management exercise and to mitigate Information Security risks costs time and money. In some cases it might make sense to mature an Information Security competency to 90% of the potential capability because the additional 10% improvement might be cost prohibitive. Developing this Information Security Roadmap and being purposeful about investment and return on investment will help gain traction for your future budget. Identify Objectives for your Information Security team. Once your Information Security Strategy is complete (or currently in development), you should begin developing your Annual Information Security Playbook. This Playbook should outline how your Information Security team delivers on your strategic Information Security objectives for the year. The projects you assign your team members to in the Playbook should tie to professional development plans. Your Information Security Playbook can also be a mechanism which to hold people accountable for the work they perform. Day's 71-80 Monitor your Information Security Program Delivery. Based on your Information Security Program Strategy and your Information Security Playbook, you have solid platform which to track progress of your strategic deliverables, the tasks that are on track and those that are falling behind. Given all the work you've put in to date you now have a good mechanism to measure your program and more importantly have an early warning system when your Information Security Program begins to deviate from the plan. This can be used as a component of your overall Information Security Governance processes. Day's 81-90 Continue monitoring Information Security Program Delivery. Depending on the number of initiatives you have in your Information Security playbook and the number of Senior Team Leaders you might need to jump in to help Junior Leaders get started and gain traction. Preset at an all Company Meeting. If you have the opportunity to do so, you should take advantage of an All-Company meeting to talk about the Information Security program, what to expect and how to engage with the Information Security team. The sooner you can get onto the agenda to present--the better, but when you do talk hopefully you've had enough time in your role to form some contextually relevant material about vision and how Information Security can help your business succeed in their goals and objectives. While everyone on the Information Security team has an obligation to perform or deliver some level of Security Awareness, this is your opportunity as CISO to do your part toward Security Awareness and share the Information Security brand with your company. Day's 91-100 BCP/DR Planning. If you have responsibility for Business Continuity Planning and Disaster Recovery, it is time to look into performing or refreshing your Business Impact Analysis (BIA) for Business Continuity Planning (BCP). Depending on the size of your business and Executive support received will drive the level of effort required here. In other words, if you need to convince other executives to "give-up" resources to help with BIA and BCP efforts then it might take a little longer to complete this effort. However, while you organizationally and politically posture your BIA and BCP efforts, you can start to collect your asset inventory for the complementary Disaster Recovery (DR) efforts. Day 101 Enjoy a celebratory beverage. You're on your way to building a top-notch Security Program. By this point you've completed some significant tasks including: completed an Information Security assessment of your Organization, built solid working working relationships with your Business Peers, improved on your Information Security budget, developed staffing development plans for your Information Security staff. completed an Information Security Strategy, Plan, and operationalized an Information Security Playbook, established a great working relationship with other Executives and the Information Security Steering Committee or Board of Directors. You have built a solid foundation for your Company's Information Security program and you'll be well served for future growth with the ability to recruit and retain top talent. Categories: Information Security

Imposing Security-Programmers should avoid starting new software in C or C++ instead use C# Computer programmers won’t stop making dangerous errors on their own. It’s time they adopted an idea that makes the physical world safer. By Simson Garfinkel on June 5, 2014 Why It Matters Flaws in commonly used software endanger financial information and other sensitive data. Three computer bugs this year exposed passwords, e-mails, financial data, and other kinds of sensitive information connected to potentially billions of people. The flaws cropped up in different places—the software running on Web servers, iPhones, the Windows operating system—but they all had the same root cause: careless mistakes by programmers. Each of these bugs—the “Heartbleed” bug in a program called OpenSSL, the “goto fail” bug in Apple’s operating systems, and a so-called “zero-day exploit” discovered in Microsoft’s Internet Explorer—was created years ago by programmers writing in C, a language known for its power, its expressiveness, and the ease with which it leads programmers to make all manner of errors. Using C to write critical Internet software is like using a spring-loaded razor to open boxes—it’s really cool until you slice your fingers. Alas, as dangerous as it is, we won’t eliminate C anytime soon—programs written in C and the related language C++ make up a large portion of the software that powers the Internet. New projects are being started in these languages all the time by programmers who think they need C’s speed and think they’re good enough to avoid C’s traps and pitfalls. But even if we can’t get rid of that language, we can force those who use it to do a better job. We would borrow a concept used every day in the physical world. Things reviewed "Heartbleed" flaw in Open SSL "Goto fail" flaw in Apple operating systems CVE-2014-1776 flaw in Internet Explorer Obvious in retrospect Of the three flaws, Heartbleed was by far the most significant. It is a bug in a program that implements a protocol called Secure Sockets Layer/Transport Layer Security (SSL/TLS), which is the fundamental encryption method used to protect the vast majority of the financial, medical, and personal information sent over the Internet. The original SSL protocol made Internet commerce possible back in the 1990s. OpenSSL is an open-source implementation of SSL/TLS that’s been around nearly as long. The program has steadily grown and been extended over the years. Today’s cryptographic protocols are thought to be so strong that there is, in practice, no way to break them. But Heartbleed made SSL’s encryption irrelevant. Using Heartbleed, an attacker anywhere on the Internet could reach into the heart of a Web server’s memory and rip out a little piece of private data. The name doesn’t come from this metaphor but from the fact that Heartbleed is a flaw in the “heartbeat” protocol Web browsers can use to tell Web servers that they are still connected. Essentially, the attacker could ping Web servers in a way that not only confirmed the connection but also got them to spill some of their contents. It’s like being able to check into a hotel that occasionally forgets to empty its rooms’ trash cans between guests. Sometimes these contain highly valuable information. Heartbleed resulted from a combination of factors, including a mistake made by a volunteer working on the OpenSSL program when he implemented the heartbeat protocol. Although any of the mistakes could have happened if OpenSSL had been written in a modern programming language like Java or C#, they were more likely to happen because OpenSSL was written in C. Many developers design their own reliability tests and then run the tests themselves. Even in large companies, code that seems to work properly is ­frequently not tested for lurking flaws. Apple’s flaw came about because some programmer inadvertently duplicated a line of code that, appropriately, read “goto fail.” The result was that under some conditions, iPhones and Macs would silently ignore errors that might occur when trying to ascertain the legitimacy of a website. With knowledge of this bug, an attacker could set up a wireless access point that might intercept Internet communications between iPhone users and their banks, silently steal usernames and passwords, and then reëncrypt the communications and send them on their merry way. This is called a “man-in-the-middle” attack, and it’s the very sort of thing that SSL/TLS was designed to prevent. Remarkably, “goto fail” happened because of a feature in the C programming language that was known to be problematic before C was even invented! The “goto” statement makes a computer program jump from one place to another. Although such statements are common inside the computer’s machine code, computer scientists have tried for more than 40 years to avoid using “goto” statements in programs that they write in so-called “high-level language.” Java (designed in the early 1990s) doesn’t have a “goto” statement, but C (designed in the early 1970s) does. Although the Apple programmer responsible for the “goto fail” problem could have made a similar mistake without using the “goto” statement, it would have been much less probable. We know less about the third bug because the underlying source code, part of Microsoft’s Internet Explorer, hasn’t been released. What we do know is that it was a “use after free” error: the program tells the operating system that it is finished using a piece of memory, and then it goes ahead and uses that memory again. According to the security firm FireEye, which tracked down the bug after hackers started using it against high-value targets, the flaw had been in Internet Explorer since August 2001 and affected more than half of those who got on the Web through traditional PCs. The bug was so significant that the Department of Homeland Security took the unusual step of telling people to temporarily stop running Internet Explorer. (Microsoft released a patch for the bug on May 1.) Automated inspectors There will always be problems in anything designed or built by humans, of course. That’s why we have policies in the physical world to minimize the chance for errors to occur and procedures designed to catch the mistakes that slip through. Home builders must follow building codes, which regulate which construction materials can be used and govern certain aspects of the building’s layout—for example, hallways must reach a minimum width, and fire exits are required. Building inspectors visit the site throughout construction to review the work and make sure that it meets the codes. Inspectors will make contractors open up walls if they’ve installed them before getting the work inside inspected. The world of software development is completely different. It’s common for developers to choose the language they write in and the tools they use. Many developers design their own reliability tests and then run the tests themselves! Big companies can afford separate quality–assurance teams, but many small firms go without. Even in large companies, code that seems to work properly is frequently not tested for lurking security flaws, because manual testing by other humans is incredibly expensive—sometimes more expensive than writing the original software, given that testing can reveal problems the developers then have to fix. Such flaws are sometimes called “technical debt,” since they are engineering costs borrowed against the future in the interest of shipping code now. The solution is to establish software building codes and enforce those codes with an army of unpaid inspectors. Crucially, those unpaid inspectors should not be people, or at least not only people. Some advocates of open-source software subscribe to the “many eyes” theory of software development: that if a piece of code is looked at by enough people, the security vulnerabilities will be found. Unfortunately, Heartbleed shows the fallacy in this argument: though OpenSSL is one of the most widely used open-source security programs, it took paid security engineers at Google and the Finnish IT security firm Codenomicon to find the bug—and they didn’t find it until two years after many eyes on the Internet first got access to the code. Instead, this army of software building inspectors should be software development tools—the programs that developers use to create programs. These tools can needle, prod, and cajole programmers to do the right thing. This has happened before. For example, back in 1988 the primary infection vector for the world’s first Internet worm was another program written in C. It used a function called “gets()” that was common at the time but is inherently insecure. After the worm was unleashed, the engineers who maintained the core libraries of the Unix operating system (which is now used by Linux and Mac OS) modified the gets() function to make it print the message “Warning: this program uses gets(), which is unsafe.” Soon afterward, developers everywhere removed gets() from their programs. The same sort of approach can be used to prevent future bugs. Today many software development tools can analyze programs and warn of stylistic sloppiness (such as the use of a “goto” statement), memory bugs (such as the “use after free” flaw), or code that doesn’t follow established good-programming standards. Often, though, such warnings are disabled by default because many of them can be merely annoying: they require that code be rewritten and cleaned up with no corresponding improvement in security. Other bug–finding tools aren’t even included in standard development tool sets but must instead be separately downloaded, installed, and run. As a result, many developers don’t even know about them, let alone use them. To make the Internet safer, the most stringent checking will need to be enabled by default. This will cause programmers to write better code from the beginning. And because program analysis tools work better with modern languages like C# and Java and less well with programs written in C, programmers should avoid starting new projects in C or C++—just as it is unwise to start construction projects using old-fashioned building materials and techniques. Programmers are only human, and everybody makes mistakes. Software companies need to accept this fact and make bugs easier to prevent. Simson L. Garfinkel is a contributing editor to MIT Technology Review and a professor of computer science at the Naval Postgraduate School. 13 comments. Share your thoughts » Credit: Illustration by Adam Hayes Tagged: Computing, Business, Communications, Web, malware, cyber attacks, cyber security Reprints and Permissions | Send feedback to the editor

Home « News « Featured Articles « Overcoming Internal Barriers to Adopting Cyber Security Overcoming Internal Barriers to Adopting Cyber Security Anthony M Freed Jun 22, 2014 Share on kindleit8 Financial limitations, a lack of resources, unclear risk appetite and multiple compliance demands are all internal forces that can impair the success of an organization’s cybersecurity efforts. The 20 Critical Security Controls (20 CSC) are one proven way to obtain a baseline for prioritization in implementing the necessary technical controls required to support a healthy network security posture. Development and advocacy for the controls, previously governed by SANS, are now the responsibility of the Council on CyberSecurity (@CouncilonCyber), an independent not-for-profit organization with a global scope which was formed to catalyze change and to accelerate the availability and adoption of effective security measures, best practices and policies. CouncilWe had the opportunity to speak with Jane Lute – President and Chief Executive Officer of the Council – and Elizabeth Ireland – VP Marketing at Tripwire – who will be discussing the challenges involved in building a robust security program at the upcoming Gartner Security and Risk Management Summit, June 23-26, 2014, at the Gaylord National Resort and Convention Center in National Harbor, Maryland. The panel includes Jeff Franklin, CISO for the State of Iowa, and the session will examine how organizations implement the third-party-validated, authoritative framework called 20 Critical Security Controls to make security practical, effective and aligned to the business. Lute most recently served as Deputy Secretary for the Department of Homeland Security (DHS), and from 2003-2009 she served as Assistant Secretary-General of the United Nations, as well as having been the Executive Director of the Carnegie Commission on Preventing Deadly Conflict. She also served on the National Security Council staff under both President Bush and President Clinton and had a distinguished career in the United States Army, including service in the Gulf during Operation Desert Storm. Lute has a Ph.D. in political science from Stanford University and a J.D. from Georgetown University. Ireland has over twenty years of technology marketing, business development and strategy experience, and has previously held leadership positions at nCircle, Extensity, MapInfo and the May Company, as well as having been a Certified Public Accountant and Computer Audit Specialist with Ernst & Young. Everyone understands that resources are not unlimited in any organization. So how can you prioritize spending on cyber security efforts? Lute says one CISO at a power company used a rather simple technique with great success: He took the popular “SANS 20 Critical Security Controls” poster and did a basic self-assessment of his organization’s security posture against the measures listed using a simple red, yellow, or green yardstick. “No outside consultants, no exotic technology. He and his team did a self-evaluation to see where they stood as compared to the best guidance out there on good cybersecurity practice — the 20 Critical Security Controls,” Lute recalled. “He showed the results of that assessment on two slides to his Board of Directors and they immediately understood the problem. For the first time, they allocated funding for cybersecurity as a separate line, and put themselves on a program to improve. The important take away from this example is that without spending a lot of money, the case can be made.” This is a timely topic for many organizations that are grappling with the changing threat environment. At the same time there are changing external threats, there are often internal issues as well. Funding is a conversation that happens around every initiative in an organization, and providing adequate resources for establishing the right level of cybersecurity is a critical topic. “Every organization has financial and resource restrictions, and we will be addressing some practical and pragmatic ways to address these issues, like what are the new avenues for funding? How can you connect the need for improved cyber security to a risk appetite in an organization?” Ireland said. “An organization needs a framework to make decisions against—this protects against unlimited spending or under spending, and clearly ties investment to what matters to the business.” Ireland says that leaving the level of acceptable risk undefined is a recipe for either spending too little or too much, and without a definition and target to move towards, it leaves too much open to chance. “Every organization can perform, they just need to set parameters to achieve against, and without that there is in essence no scoreboard,” Ireland said. “Setting the level of acceptable risk is a part of good management, and while the cybersecurity team should have input, it is the business that needs to accept the risk – in many organizations this is a challenge as measuring cyber-risk is a new discipline.” Lute points out that companies need to know what’s connected to their networks, what’s running or trying to run on their networks, limit and manage those who have admin privileges, and have in place an automated system like DHS’s continuous diagnostics and mitigation, else they are signaling that their appetite for risk is unlimited. No one wants to send that message. “One of the benefits of the 20 Critical Security Controls is that they represent a risk judgment by a respected segment of the expert community, that you can prevent 80-90% of all known attacks by implementing and staying current on basic cyber hygiene,” Lute said. “No enterprise needs to conduct a cyber risk assessment as if nothing were known. We know what to do to get you to a baseline of protection that prevents the vast majority of all known attacks.” Ireland agrees, and says it is critical to be in a position to register any early indicators of breach activity. “A baseline is all about that, especially on your critical servers and infrastructures, discerning a ‘known secure state’ is a must. You need to be able to revert to that state, understand the scope if you have had any changes, and to be able to identify in real-time what may look like minor changes but may turn out to be early indicators of breach activity.” The Gartner panel session should appeal to anyone who wants to have the support of the wider community of “fellow travelers” on the security journey to help them overcome obstacles in their organizations in order to adopt known best practice – from other business lines competing for resources, from C-suite executives who may not understand the persistent threats, or from Boards that haven’t yet turned their cybersecurity discussions into support for effective action. “People should leave this conversation determined to do the right thing. Implementing the 20 Critical Security Controls helps prioritize the most important actions that every enterprise should take first to strengthen their cybersecurity posture,” Lute said. “People should also leave this conversation confident that they are part of a wider community committed to implementing known best practices, and should be aware that resources exist to help them on this journey. Tell us your story and we will share your example. We want to celebrate more cybersecurity heroes.” Lute further points out that failing to implement the 20CSC will almost certainly mean that accountable officials will at some point have to face their Boards, their shareholders, and their customers and admit that they didn’t observe the minimum standard of due care when it came to protecting their information, their identities, the intellectual property and the IT systems that the enterprise uses to deliver value. As the National Governor’s Association call to action on Cybersecurity (“Act and Adjust”) says: “…the Council on CyberSecurity’s Critical Controls for Effective Cyber Defense is an industry standard that provides…a security framework that can strengthen…cybersecurity defenses and ultimately protect information, infrastructure, and critical assets. Compliance with that standard will provide a baseline of defense, deter a significant number of attacks, and help minimize compromises, recovery, and costs.” Lute notes that the Council and the Center for Internet Security have joined forces with the National Governors’ Association Homeland Security Advisers to launch the National Cyber Hygiene Campaign. “In the coming year we will showcase best practice, provide tools to help others adopt basic cyber hygiene based on the 20 Critical Controls and comply with the NIST cybersecurity framework,” she explained. “Raise your hand and tell us who you are — we want to focus on you — the professionals and enterprises out there showing how, every day, that best practice can become common practice.” Lute points out that no enterprise in the marketplace delivers any value today without relying on the Internet, and it will not be possible to deliver that value without having basic cyber hygiene in place. “Companies can deliver products and services, improve sales, reach customers, and run themselves effectively with sound cybersecurity practices in place,” Lute said. “It doesn’t have to be either or.” Ireland notes that while it is completely an organization’s choice as to which framework they choose to implement, the key takeaway here is that every organization should definitely make that choice. “This is going to be an elevated discussion at the boardroom level as these questions will continue to be asked: Are we doing what is considered best practice? What are other organizations doing? Can we measure our progress against our peers?” Ireland said. “Besides, there is the concept of quick wins, and I always like a pragmatic approach to solving a problem – make progress, and then move on to solving the harder problems.”

CISO Educational Requirements To start on the path to becoming a CISO, interested IT professionals could pursue a bachelor's degree in a related field, such as computer science, business administration or information science and security. Students may take relevant classes, such as programming languages, database management, technical writing and calculus. In order to hone the business management skills required of this position, candidates would benefit from a master's degree program in business administration (MBA) with a specialization in information security management. Aspiring CISOs enrolled in such an interdisciplinary MBA program can study marketing, accounting and finance, as well as Web analytics and computer system security. http://education-portal.com/articles/Chief_Information_Security_Officer_Job_Description_and_Requirements.html

Home › Incident Management Microsoft Unveils New Threat Information Exchange Platform By Mike Lennon on June 23, 2014 inShare1 Microsoft has launched a limited preview of a new security and threat information exchange platform that enables users to set up their own independent threat sharing communities to exchange information such as suspected malicious URLs or IP addresses and analysis of malware. Called “Interflow”, the platform runs on Microsoft’s Azure cloud platform and enables customers to identify and respond to threats faster. Microsoft describes Interflow as a “distributed system where users decide what communities to form, what data feeds to bring to their communities, and with whom to share data feeds”. The use of open specifications STIX (Structured Threat Information eXpression),TAXII(Trusted Automated eXchange of Indicator Information), and CybOX (Cyber Observable eXpression standards) means that Interflow can integrate with existing operational and analytical tools through a plug-in architecture, Microsoft said. “Many security professionals rely largely on manual methods for collecting, analyzing, and consuming information about threats like malware and botnets,” Microsoft explained. Because that data isn’t easily shared among organizations in a consistent, common format, Microsoft has implemented the open formats to prevent users from having to be locked into to proprietary data formats, appliances or subscriptions. With that being said, many larger organizations will still opt to use multiple threat information sources and vendors. Data added by participants is shared automatically and almost instantly in machine-readable formats and enables community and peer-based sharing. Whether communities are formed by Computer Emergency Response Teams (CERTs) or by industry, Interflow can help members of a community stay more secure by allowing them to: · Combine their individual analysis of malware to more completely understand the threat landscape and better identify variants. · Rapidly upload suspected malicious URLs identified by others in the community into firewalls and defense system to automatically block potential threats. · Work together when under active attack from new malware – sharing analysis at near instantaneous speeds. “What the cybersecurity community will benefit from is a more productive way to collaborate and take action,” Zheng Bu, VP of Security Research at FireEye, said in a statement. “It is encouraging to see Microsoft invest in such a platform, and drive it forward for the greater good of the community.” Microsoft said that it will share the security and threat data used to protect its own products and services with the Interflow communities during the private preview and that Interflow will be available to all members of MAPP in the future. Organizations and enterprises with dedicated security incident response teams can inquire about the private preview through their Technical Account Managers or by emailing mappbeta@microsoft.com.

Home News Blogs and Opinions Expert Panel Marketing Jobs Directory Training Contact Us Free_Ebook protect-you-mac-from-virus-2-slider While High School Freshmen Hack ATM, Indirect Attacks Grow More Stealthy ATM I read with interest the news that two 9th graders (14-yr olds) in Canada found an online manual for a Bank of Montreal (BMO) ATM machine, and hacked in to Operator mode. The “damage” these two inflicted was to change the ATM surcharge (the amount the ATM owner charges the consumer during the transaction) to one cent. No money was extracted, and given their intent and honesty, what they did could be viewed as a “Robin Hood” moment. BMO’s response was minimal, as they issued the usual comment that “steps will be taken” to ensure it does not happen again. What that presumably means is they will change the default password to stop idle access from anyone with the spare time to google “ATM OPERATING MODE MANUAL” and follow a few links. ATM Default Passwords Readily Available These days it’s very simple to find this information online. In about 30 seconds, I found a link to one ATM manufacturers’ manual, and in another 30 seconds, on page 16, all three default passwords (albeit with a caveat saying they should be changed). The critical issue is what Operator Mode can do. Operator Mode can, for example, allow you in to Test Mode. Test mode allows you to ensure, for example, that the Cash Dispenser actually works (by dispensing a bank note). There are some safeguard in place, so that the ATM will dispense a single note to the Reject Bin, inside the ATM behind a lock and key, to reduce the fraud possible in test mode. So all’s well then? Not entirely. The manuals also provide guidance on how to override the Test Cycle parameter, to run the test continuously, instead of once (ie a single note). But the notes will still go from the Dispensing Bin to the Reject Bin, so in this case, everything is still fine. But what if you could change a few lines of code, to change the parameter that routes money during the test to the dispenser, instead of the Reject Bin? Combined with the unlimited Test parameter? Bingo! You cash out. How likely is it that the code on ATMs can be changed? You only have to look to the Target breach to see an example of that sort of indirect attack. In that case it was POS terminals, infected with malware code that collected the credit/debit card information for over 70M people. Another example happened about 18 months ago, where fraudsters over-rode the daily limits of debit cards to make unlimited withdrawals from cash machines. The loss was $40M in 10 hours, and part of the attack was enacted by simply changing a parameter on a database that tells the ATMs what to do and how to behave. This was one of the drivers behind the recent Advisory from the FFIEC in April concerning ATM and Card Authorization Systems. http://www.fdic.gov/news/news/financial/2014/fil14010.html Indirect Attacks of Even More Concern Indirect attacks are the new battleground. So many organizations have bolstered their security around the direct form, while ignoring the indirect. In 2012 for example, Microsoft reported that PCs were being shipped with malware already installed. If they can infiltrate the PC manufacturing process, it’s not hard to believe they can do the same with ATMs or POS terminals. When it comes to banks, direct attack defenses are usually via 2nd factor authentication, device identification and behavioral analysis engines. To date, banks have had fewer options to defend against indirect attacks, especially if they want to integrate these with their direct attack defenses. The indirect attack broadly falls in to two categories – phishing and malware – with the former often being the pre-cursor to the latter. This was the case with the RSA breach 3 years ago where a phishing email “from HR” loaded malware via an excel sheet – giving attackers access to many RSA customers. Phishing today also increasingly uses social media (fake posts and false “tiny” URLs), and is more prevalent than ever. According to the Anti-Phishing Working Group, over 111,000 unique phishing sites launched just in the last three months of 2013. http://docs.apwg.org/reports/apwg_trends_report_q4_2013.pdf Sophisticated fraudsters do not care about if their victim have direct attack defenses in place. They’re leaving the direct hacks to the 14-yr olds, and increasingly leveraging cleverly deployed malware to conduct stealth attacks. In the modern era, organizations have to expect indirect attacks in many guises. The more they can prevent an attack at the outset from a solution that offers shared intelligence, flexible layers of resilience, the less reliance they have to put on traditional defenses – defenses that can be circumvented by 9th graders who are good at using Google. Jeremy Boorer, Director – Europe, Middle-East & Africa, Easy Solutions ABOUT EASY SOLUTIONS Easy SolutionsEasy Solutions delivers Total Fraud Protection® to over 150 clients, with over 40 million end users. The company’s products protect against phishing, pharming, malware, Man-in-the-Middle and Man-in-the-Browser attacks, and deliver multi-factor authentication and transaction anomaly detection. For more information, visit http://www.easysol.net, or follow us on Twitter @goeasysol. inShare2 Please Share: Share on Tumblr Digg Email June 23, 2014 Cyber Attack Forces Code Spaces Out Of Business Back Leave a Reply Your email address will not be published. Required fields are marked * Name * Email * Website Comment Notify me of followup comments via e-mail. You can also subscribe without commenting. Notify me of follow-up comments by email. Notify me of new posts by email. advertisement1 Sign Up To Our Newsletter! advertisement2 Popular Latest Today Week Month All Serious WordPress Issue Bypasses The Two-Factor Authentication Serious WordPress Issue Bypasses The Two-Factor Authentication Cyber Attack Forces Code Spaces Out Of Business Cyber Attack Forces Code Spaces Out Of Business How To Be Anonymous On The Internet How To Be Anonymous On The Internet 10 Steps For Safely Banking Online 10 Steps For Safely Banking Online Security Everywhere: One Unmanaged Desktop Is All It Takes Security Everywhere: One Unmanaged Desktop Is All It Takes advertisement3 In Other News… CoinDesk- 500 Million Dogecoins Mined by Unknown Hacker in Malware Attack Use The Board - How Hackable Is Your Life and Learn To Protect Yourself Secure Honey - Creating An Antidote For Android Simplelocker Ransomware advertisement4 Offical Stuff Terms & Conditions Privacy Policy Disclaimer Copyright Notice Contact Us Top 25 Female Infosec Leaders to Follow on Twitter Infosec Job Board

Suspicious device” explodes at Nogales power plant Jun 11 2014 in Featured Articles, Incident Reports by Homeland Security NTARC News A makeshift bomb exploded at a Nogales, Arizona power plant Wednesday, rupturing a large fuel tank and prompting the FBI and federal bomb experts to respond. Local officials were alerted at 9:30 a.m. to a call of “suspicious activity” at the UniSource Energy Services Valencia Plant. An explosion had ruptured a diesel storage tank and caused what Nogales Police Lt. Carlos Jimenez described as a relatively small spill that was confined to the immediate area.