(ISC)2 Blog

FISMA 2008 - What is it and what will change?

Those that have supported the implementation of the Federal Information Security Management Act (FISMA) of 2002 have seen a significant change and focus of information security in federal government over that past several years, including the increased attention placed on agencies through OMB policies requiring them to implement a multitude of standards and guidelines.

Obviously, right out of the box, I have seen a mix of opinions from the increased cost of security, including many negative views on the reactive approach government leaders have taken to introduce new security related policies.  From the perspective of a security professional, the government has not fully made federal executives a vested champion for supporting these policies, and should require these executives who have the budgetary authority to present the value proposition FISMA and related policies/guidelines bring to the mission and business leaders of the agencies.  In many agencies, FISMA compliance has become an embedded part of the IT organization, rather than managed directing from the offices of the head agencies.  Although the CIO plays a critical role in executing the FISMA requirements within the organization, the business and mission are really the drivers when establishing appropriate objectives for confidentiality, integrity, and availability.

FISMA 2008

(http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=110_cong_bills&docid=f:s3474rs.txt.pdf), which passed on October 1, 2008 through the Senate Homeland Security and Governmental Affairs Committee (see status page of bill - http://www.govtrack.us/congress/bill.xpd?bill=s110-3474) will increase the visibility on security controls applied to information system.  This would greatly increase the importance placed on agencies to more efficiently and creatively implement security to ensure that additional overhead costs associated with the additional mandates, which according to the Congressional Budget Office (http://www.cbo.gov/ftpdocs/99xx/doc9909/s3474.pdf) will add an additional $150 million to currently agencies annual expenses (http://www.fcw.com/online/news/154252-1.html), do not adversely impact mission requirements.

So what changes should we expect?

The FISMA 2008 bill provides an enhancement to the current security of the Federal Government by amending the original text to add additional language to expand the role of FISMA and in some instances creates more strict oversight of day-to-day security operations.  Below are just a few of the major changes that were noted:

1. Creates the Chief Information Security Officer (CISO) role, and vest the authority for enforcing security and compliance with FISMA

2. Establishes the CISO Council within the executive branch where executives from across the federal government, including, but not limited to the US-CERT, Intelligence Community Incident Response Center, DHS National Cyber Security Center, DoD, ODNI, Civilian Agencies, and OMB

3. Enhances the continuous monitoring process, through the requirement to have annual independent audits rather than allowing agencies to perform self-evaluations between audits performed as part of the system accreditations

4. Requires additional reporting from DHS related to a detailed explanation of the state of the federal security posture (outside of the annual FISMA reporting from OMB)

Among the challenges faced by the Federal Government (including a new Administration change), focus should include additional work by on capturing more security metrics, so that agencies are held accountable for allocating security funding appropriately.  Currently, budgets include security costs are not tracked appropriately.  For most agencies tracking should be directly managed by Agency Heads to ensure monies are really spent, and measures can be taken to itemize where cost increases are not producing a value.  This will demonstrate a confidence to the business unit leaders that have the role of allocating security costs to their programs and make security a component that does in fact deliver a return-on-investment for the business units that must manage the balance between meeting mission requirements and protecting their information.

Cross Organizational Collaboration - Securing the World with Cooperation

We just completed an awesome conference in Taipei, so I posted some Comments on Proxy Caches and Web Application Security (OWASP Taipei) on my blog.

Like many of you, we are members of multiple security-related organizations including non-profit, government, military, educational and commercial organizations. I happen to be both an (ISC)² member as well as chapter leader for (the new chapter) OWASP Thailand.  Many (ISC)² members serve on myriad IT-security boards as directors and advisors.  In addition, various organizations support and sponsor each other; for example, (ISC)² is an OWASP sponsor.

As professionals, it is our responsibility and ethic to positively and proactively support our profession, including other IT-security related organizations.  Increasingly, cybersecurity is becoming one of the most challenging global problems we face.  Web servers and transactions know no boundaries.

Because of this, our professional responsibility, indeed the core fabric of our ethic, is to offer support and foster cooperation between and across security organizations.  Cross organizational collaboration is very important. The only way we can hope to secure the very vulnerable and fragile cyberworld we have created is by the global cooperation of security related organizations and experts.

Information Security During Economic Uncertainty

Most of the world has been understandably shaken by the turn of events in the financial arena these past few weeks. Whatever the outcome, whenever economic uncertainty arises, information security professionals inevitably ask themselves the question: "Is my organization going to cut security budgets?"

The short answer is, "They shouldn't."

Fortunately, times have changed considerably since the early days of security which is now seen as an essential business requirement such as accounting and legal. It has become a business function that is as important as anything else in a 21st-century organization.

It's true that there may be an initial knee-jerk reaction from the C-suite regarding security budgets; but I believe common sense will prevail in most cases. If someone went to the CFO and said, "I can save us $10,000 this week but in the long term it's going to cost us $300,000 in harm," no CFO in the world would think it was a good idea. That principle applies even more in these times of economic uncertainty.

Also, issues such as governance, risk, and compliance are not optional anymore - they are mandated by the government or other regulatory bodies as well as boards of directors, shareholders, etc. As a consequence, when organizations start looking at ways to more effectively manage the budget, it must take into account that effective security programs keep the organizations running at peak financial performance. Not minding security best practices places any financial gains in serious danger.

That said, security professionals need to be able to reassure management that whatever you're spending is being spent properly and the work is being done as efficiently, effectively and realistically as possible. And you need to make sure your people are at the top of their game when dealing with risk/compliance issues more so now than ever before.

Your organization still needs properly trained employees in order to protect infrastructure. The bad guys don't feel the pinch of a recession - in fact, they are more active because their mindset is that when things get tough, people will let down their guard and focus on other priorities. In addition, common sense says economic downturns tend to create more bad guys, not less. Your organization will not be saving money if it has to rebuild systems or go into emergency operations mode because it didn't use best practices or didn't have people trained properly.

In addition to training, professional organizations such as (ISC)², ISSA, ISF and others provide value during difficult economic times through its peer networking functions, both online and in real-world meet-ups. When security professionals talk to each other, they learn from each other's experience and become more cost effective rather than trying to go it alone. There's a tremendous amount of value in leveraging what others are doing and pooling resources when it comes to professional organizations and security people.

On another topic, I would like to let the readers of the (ISC)² blog know that I have been appointed the first president of the Information Security Forum (ISF). I am looking forward to having ISF work more closely with (ISC)² and other top global security organizations on the pressing issues facing us all as professionals. I will be retaining my position on the (ISC)² board as well as my position as ISSA president. I hope to continue blogging here as well.

Securing Software Through Professionalism

The challenge of software vulnerabilities has been discussed by many in the information security industry for several years now. Not only have there been several major breaches due to unsecured software, the costs continue to rise for those of us who have to maintain systems and constantly patch the vulnerabilities that are found.

As we know, the problem is not isolated to any particular piece of software – it’s across the board, whether it’s operating systems, word processing, new media or any other application that can make enterprises open to attack.

After hearing from our members and those who write and develop software about this problem, (ISC)² formed several expert working groups to discuss possible solutions. The consensus was that while the software industry has made some progress in improving the secure coding and development of software, it hasn’t moved quickly enough.

These experts agreed that there are security issues found at all different steps in the software lifecycle and that we need to look at software security holistically, from the very beginning of design, to implementation, maintenance and disposal.

The end result of these conclusions is the Certified Secure Software Lifecycle Professional (CSSLPcm), a new certification announced this past month by (ISC)² to validate an individual’s understanding of security best practices throughout the software lifecycle.

Code-language neutral, the CSSLP is applicable to anyone involved in the software development lifecycle, from analysts, developers, software engineers and software architects to project managers, software quality assurance testers and programmers. It is complementary to the CISSP but there is no other certification required to obtain it.

CSSLP candidates must demonstrate four years of professional experience in the software development lifecycle process or three years experience and a bachelor’s degree (or regional equivalent) in an IT discipline.

The seven domains of the CSSLP CBK are:

• Secure Software Concepts
• Secure Software Requirements
• Secure Software Design
• Secure Software Implementation/Coding
• Secure Software Testing
• Software Acceptance
• Software Deployment, Operations, Maintenance and Disposal

We are very proud to note that a wide range of respected organizations have expressed their support for the CSSLP, including Microsoft, Symantec, DSCI (NASSCOM), SANS, SRS International, Software Assurance Forum for Excellence in Code (SAFECode), Cisco, Xerox, SAIC, ISSA, and Frost & Sullivan.

The first CSSLP exam is scheduled for the end of June in 2009. Currently, (ISC)² is seeking qualified professionals who meet experience and other requirements to participate in the exam assessment. They will become the first CSSLP holders and be asked to contribute to the exam development process and assist in other program development tasks. Applications for the CSSLP experience assessment will be accepted from Sept. 25, 2008 through March 31, 2009, with the first education seminars slated for Q1 2009. For more information and to register for the experience assessment, please visit www.isc2.org/CSSLP.

I hope you will support this endeavor to make our software and our enterprises more secure in the years to come. I welcome your suggestions and comments on this exciting new initiative from (ISC)².

Visualization for Command and Control of Cyberspace Operations

AF083-022  TITLE: Visualization for Command and Control of Cyberspace Operations

TECHNOLOGY AREAS: Air Platform, Information Systems, Space Platforms, Human Systems

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.

OBJECTIVE: Develop visualization techniques for planning and execution of Cyberspace operations.

DESCRIPTION: Fulfilling the Air Force mission “… to fly and fight in Air, Space, and Cyberspace” requires effective C2 tools for the observation, planning and execution of cyberspace operations. Conventional battlespace visualization tools were developed for the physical world (i.e., geospatially oriented), where the battlespace, weapons and effects are concrete, often observable entities. Cyberspace and its critical electronic infrastructures are an artificial world that must be created, modified and sustained by the warfighter. This artificial world of cyberspace has concrete links back to the physical world that shape the information landscape, affect the decision-making process, and control the communication channels crucial to C2.

Standard, geospatially oriented C2 tools are not suitable for providing cyber combatants with comparable situation awareness to understand events, evaluate options, and make decisions in the electromagnetic domain. The combatants in the cyber domain needs to be able to quickly see and understand not just the physical relationships of the traditional battlespace, but also the logical relationships and information dependencies in the abstract landscape of cyberspace. Cyber C2 visualizations need to provide information for strategy, tactics and execution of effects that may, or may not, have physical correlates. Examples of these cyber events include network attack detection, attack identification, damage assessment, denial of service (DOS) warnings, and information warfare or cyber-attack operations.

For example, a commander may be planning to intentionally disrupt a portion of his network to investigate a cyber-attack. He will need to understand what ripple effects will occur across the functionally diverse and geographically distributed network. These ripple effects will have both a cyber component (e.g., locations that will lose connectivity or suffer degraded performance characteristics) and a real-world component (e.g., information about enemy forces may be unavailable or delayed, reducing blue force effectiveness) that must be visualized, explored and tasked from within his C2 tools.

Decision makers will greatly benefit from innovative visualization tools that can improve their understanding of all aspects of the Cyber domain. These aspects include 1) the current state of the information environment, the physical and virtual battlespace and enemy and friendly capabilities and vulnerabilities; 2) the scope and scale of courses of action that affect information or information networks; 3) the primary effects and ripple effects of an operation in both the physical and cyber battlespaces, and 4) the risks for collateral damage associated with cyber warfare activities.

PHASE I: Identify cyberspace characteristics relevant to C2 visualization. Identify correlation methods and visualization techniques to understand battlespace, operations, and effects. Define metrics to evaluate efficacy. Document results in a written report, including mockups of proposed visualizations.

PHASE II: Construct a working prototype to demonstrate integrated visualization of cyber data showing 1) the status of information environment, 2) its effect on the conventional battlespace, and 3) the status of information operations. Evaluate effectiveness using metrics defined in Phase I.

PHASE III / DUAL USE: Military application: Additional military applications include command and control environments, like the Air Operations Centers (AOCs). Commercial application: Monitoring and defending infrastructures (e.g., financial and energy) against cyber-attacks. Visualization cyberspace is beneficial for security of commercial communication and information networks.

REFERENCES:

1. ‘Air Force leaders to discuss new ‘Cyber Command’ http://www.af.mil/news/story.asp?id=123028524

2. Laura S. Tinnel, O. Sami Saydjari, and Joshua W. Haines, An Integrated Cyber Panel System, IEEE Computer Society,

3. Anita D’Amico and Stephen Salas, Visualization as an Aid for Assessing the Mission Impact of Information Security Breaches, IEEE 2003.

4. Tim Bass, “Cyberspace Situational Awareness Demands Mimic Traditional Command Requirements,” AFCEA Signal Magazine, February 2000.

KEYWORDS: visualization, cyber, human factors, planning, situation awareness, command and control, HCI

Reference. SITIS Topic Details, Visualization for Command and Control of Cyberspace Operations

See also:  http://www.dodsbir.net/solicitation/sbir083/af083.doc

Contingency planning for Information Security

Until the last few weeks, Information Security Managers the world over have been struggling along as always, doing as much as they can possibly do with often limited resources and uncertain support from the rest of management.  Suddenly, inadequately controlled risks in the finance sector have triggered an economic meltdown that affects us all.  It's a classic "something else happened" scenario beloved of contingency planners everywhere. 

Given the global financial crisis, it's likely that information security budgets (along with all others) are going to be stretched taut for a while.  So what is the best way for us as information security professionals to rise to the challenge?

I've already seen some pundits taking the line that information security is 'essential' and can't possibly be cut.  Attempts to justify information security expenditure on cost-benefit grounds are tricky at the best of times.  While I personally enjoy the ongoing discussion around Return On [Security] Investment, the fact that we as a profession haven't pinned this down as yet implies that our arguments are not nearly as clear-cut as we would like to believe.  In a global economic downturn, I doubt this kind of approach will succeed.  Important budgets will be cut.  Good people will be laid off.  Pet projects will be cancelled.  In this mode of thinking, security (like risk management) is an inherently negative concept and a tough sell: people hate having to spend on something that might never happen so when times are tough, information security is inevitably a candidate for the chop.  Being the prophet of doom, issuing dire warnings about the potential outcome of security budget cuts and the need prioritize security spend, is perhaps not the most effective response to the crisis.  Even managers who accept that security is 'essential' face equally valid demands on the organization's resources from other 'essential' activities.  Arguing the toss over which is the more 'essential' is simply not helpful and makes no friends.

An alternative is for us to work with management to make changes that 'create the least harm'.  I'm talking about us accepting that cuts are inevitable but we should be managing the information security function to obtain the best possible value from the diminishing resources we have - not for our own selfish needs but for the organization as a whole.  Perspective is important!  Information security is a means for the organization's ends, not an end in itself.

Overt and deliberate alignment with corporate priorities, initiatives and missions has long been a successful strategy for information security and I see no reason to doubt it now.  The trick, though, is to realize that those corporate priorities have almost certainly changed since the financial markets took a tumble, and change creates both risk and opportunity.

For example, we know that job losses and budget cuts throughout the organization put employees (staff and managers) under extreme personal stress.  In such circumstances, selfish behavior is a typical human response.  People who are being laid off sometimes feel justified in taking "what's rightfully theirs", which may well include intellectual property and IT hardware.  Workplace security is an important consideration, and information security is part of the solution to the insider threat.

Likewise, commercial competitors facing financial hardship are likely to be more aggressively competitive than ever.  They may be tempted to exploit vulnerabilities in suppliers', customers', partners' or competitors' information security controls to gain the upper hand in sales or merger & acquisition negotiations, for example.  [Note: I'm not proposing or condoning the use of aggressive information security techniques.  Ethics still have meaning and value, even in a crisis.] 

Aside from such generic scenarios, we need to be fully engaged with senior management, actively participating in the strategic discussions around What Must Be Done Now in order to spot and respond to specific risks and opportunities as they arise.  Returning to the contingency planning point I made earlier, we ideally need to be part of the crisis team or at least to be able to influence it through information security's friends in high places. 

You do have friends in high places, don't you?  Either way, now is a great time to be out and about, talking to managers throughout the corporation about their objectives, their worries, their needs.  Strategic alignment doesn't often happen by chance.  Creative managers make their own opportunities.

DRP and BCP Step 1: Establish Communications

I have seen a number of security professionals with a lack of operational experience in disaster recover and business continunity planning address both DRP and BCP as if it was a templated, academic exercise.   This is one of the worse possible approaches for DRP.    So, let's make this quite simple.

The most important first step that must be done in any disaster recovery situation is to establish communications.  In most cases this means that you need to establish communications between people within an organization and also external to the organization.   

In Thailand, for example, I see many folks approaching DRP and BCP incorrectly.   They promote and advocate an academic approach that is more confusing than useful, and in many instances, these approaches are a waste of time and precious resources.   The reason is simple.  If you focus on a solid communications recovery plan first you will solve the most critical part of any disaster recovery scenario.

For example, let's say you are the IT security person in charge of a major manufacturing company.  A natural disaster occurs and destroys your main building and your data center.   How does the CEO communicate with employees?  How does the company communicate with their customers?  How does the company communicate with the news media and analysts?  Who will be responsible for communicating with whom?   How will they do it?    What happens if a disaster knocks out telecommunications (for example the mobile phone network), what is the plan?

In other words, in every disaster recovery planning situation the most important first step is to insure that you have a solid communications plan in effect and you are ready to execute than plan under various disaster scenarios.  In addition, you need to distinguish between disasters that knock out national communications backbones and more specific corporate disasters, like a fire in a data center. 

Sometimes I am surprised at how folks with little operational experience can be driven by academic studies, confusing standards and templated approaches to security, when all that is required is a bit of common sense and an understanding of what is important.  These is nothing more important, in any disaster recovery situation, than establishing communications.

SSH Keys

At my previous position as a Systems Administrator, I got to experience firsthand the convenience of using SSH keys. My personal SSH key was encrypted and password protected, of course. This allowed for quick and easy authentication to systems as my user account. As long as you kept your SSH daemon up to date this was actually reasonably secure. This greatly reduces the amount of passwords you have to remember in a Unix or Linux environment which is not utilizing any kind of directory services.

The second and even more useful aspect of SSH keys is from an automatic administration standpoint. For example, I once had to devise a method for devices that were at customer's sites behind various firewalls, proxies, etc. to "phone home" with the minimal amount of configuration on the client's end. After considering various ideas I came up with a solution that wasn't elegant but got the job done effectively. I had the remote devices automatically connect to the central SSH enabled server via an SSH key and open a remote port forwarding connection using a randomly assigned port on the central SSH server. The remote device wrote a line in a log file indicating it's machine name, the IP it had connected from, and its currently used port. This allowed me to use a simple script to connect to the machine by host name. This allowed for various automated remote administration techniques to be utilized. As the automated connection back to the other remote device was not using the root user, we found this technique to be an acceptable risk.

Interpreting the Law

In the never-ending battle against identity theft, a proactive event recently took place in Texas:  a company was charged with improperly dumping patient records.  This was discovered before any actual identity theft was reported. 

Per the Texas 2005 Identity Theft Enforcement and Protection Act: "A business shall implement and maintain reasonable procedures, including taking any appropriate corrective action, to protect and safeguard from unlawful use or disclosure any sensitive personal information collected or maintained by the business in the regular course of business. A business shall destroy or arrange for the destruction of customer records containing sensitive personal information within the business's custody or control that are not to be retained by the business by:  (1) shredding; (2) erasing; or (3) otherwise modifying the sensitive personal information in the records to make the information unreadable or undecipherable through any means." 

But there something that still bothers me about this act--the technical details.  For example:

1. Shredding: cross-cut or strip cut?
2. Erasing:  low-level multi-pass erase, zero out the data, or just delete the files?
3. Modifying sensitive data:  change just the name and SSN, or include data of birth, address and any account numbers?

How an organization complies with this act and makes "the information unreadable or undecipherable through any means" remains open to interpretation.  And that's the problem.  Throwing strips of sensitive data into the dumpster instead of the actual documents isn't much of an improvement. 

Organizations want to elicit the services security professional  (e.g. a CISSP) to properly safeguard and dispose of their sensitive data, and to meet their legal obligations.  Otherwise, they may be giving themselves a false sense of security.

PCI-DSS v1.2 - My Thoughts, Concerns & Questions

Having had the opportunity to go to the 2008 PCI-SCC meeting in Orlando this year, that just so happened to be conveniently 5 minutes down the street from my office. And having had a couple of weeks to digest the new PCI-DSS v1.2 standard, here are some of my thoughts, concerns and questions. I’m not going to go into all the minor changes or clarifications, but rather the ones I feel have the most impact to the most organizations. One of the first ones I think that jumped out to allot of us was the notes added to requirement 6.1, concerning patch management. The testing procedure under 6.1.b states that patches rated critical must be shown to be installed within one month, however the following has now been added under the NOTES of requirement 6.1;

6.1 - Note: An organization may consider applying a risk-based approach to prioritize their patch installations.

Keywords are “may” and “risk-based” here.

Now I’m not going to let the old I.T. security administrator in me get up on my infosec soapbox on this topic, because it is a very subjective area with many variables that most auditors in general do not always understand (I’m talking about arguing risks). This addition under the notes to the overall requirement, although welcome to all, particularly systems administrators, does in my opinion have a downside. My concern is from an I.T. security perspective, not only a compliance one, where I think many organizations will once again not put enough resources behind a solid but practical patch management program and become laxed once again.

Ok let me get back on track here, testing procedure 3.4.1.b for requirement 3.4.

3.4.1.b - Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

“Stored Securely” being the key word here, the change and relief I think here is that having the keys stored locally on the system isn’t a deal breaker. Although one may argue a best practice may be to have them located somewhere else, it is no longer required.

Another one I find worth mentioning and would also like to get a general consensus is on 4.2 where instant messaging has now been added to the language. Here’s an area where both the I.T. security geek and compliance manager in me are in complete agreement. I like to have strong controls including when possible content controls on all communication channels that have the ability to travel outside my network. My question is where the consensus on both scope and controls will fall on instant messaging.

Requirement 11.4 has now been thankfully changed to where it now states and/ or in reference to IDS and/ or IPS. I can say that 99.9% of any network administrators I have ever worked or spoken with always stayed away in general to any device that has the access or ability to change routing and/ or firewall tables, a decision I 100% agree with.

In requirement 5.1 I welcome the terminology being changed from anti-virus to “malicious code”, it makes the requirement more flexible. But one new development in the requirement that many may think is trivial but does raise some long term concern with me is the addition of the word “Rootkit”. Now I agree this is a form of nasty code that needs to be addressed, but I would like to get a consensus on this one. I have two questions; 1. Does this now mean that anti-virus installations on Windows servers will have to have a rootkit component in them, and 2. The phrase “commonly affected systems” used under requirement 5.1, does this now mean that UNIX systems down the road will need to have some form of rootkit detection running on them. I know most will agree that will probably be a long way from now, I just curious if thats the direction we are going, just a thought.

OK, I had to come back and add this one, I almost forgot, the additions and changes to requirement 11.3. and the testing procedures, first lets hit the requirement;

11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification.

Ok the thing that caught my eye here immediatly was "Internal". Now as a former I.T. security administrator I agree 100% with a vulnerability management program that includes limited internal vulnerability scans of production servers that are online and where warranted limited penetration tests, particularly sensitive web applications. But I can’t say I agree with a requirement that now requires full penetration tests on all in-scope hosts internally. I had a discusion with a fellow compliance officer and said no matter how secure our systems are, a good pen tester or black hat can with enough effort break into them, including using social engineering methods. I rather see the PCI-SSC be more strict and put more emphasis on strong system security baselines, patch management, logging and incident reponse than add this requirement.

My second concern is with the language added to the testing procedure 11.3.a.

"Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment. Verify that noted vulnerabilities were corrected and testing repeated".

The phrase that pops out at me here is "testing repeated", does this now mean I have to run penetration tests until all of the security issues identified in the test have been corrected. So is this now going to put me in a situation of constantly performing penetration testing all year round as my environment changes and new vulnerabilites are introduced.

The jury is dismissed on this one.