CISO Today

IT Certifications Losing Their Luster

Edward Liebig CISSP CISM CIPP — Tue, 01 Dec 2009 16:36:00 GMT

Recently CIO Insight released a slide presentation that outlined the loss of traction and salary command

http://www.cioinsight.com/c/a/Careers/IT-Certifications-Lose-Luster-626640/?kc=CIOQUICKNL12012009FEA1

As an Information Security professional I was disturbed by this study. Even though the IT Security certifications gained respect in this study it leaves the rest of the IT industry a bit more open to "less than industry accepted practices" when non certified personnel fill roles that impact the design and deployment of IT resources. The point of certification is not only to prove someone CAN do a job but also to prove they have the knowledge of how to perform their function properly aligned with industry norms.

More helpful than raw percentiles, this study should have dove into a root cause analysis of the decline in certification’s importance. If it was a monetary driven distain and salaries are at a peek, holding fast to the requirement of certification while offering set salary ranges could persuade certified individuals to fill the positions. As employment opportunities become scarcer, more qualified personnel will take the positions.

If the fact that certifications are seen as easily attainable and less effective then that is a whole different story. More concentration and effort would be demanded of the certifying organizations to ensure all recipients are well versed in the course material. More stringent testing and CPE maintenance may be demanded.

Either way, as an industry, Information Technology needs to maintain continuity and standardization to be effective. Interoperability and secure cross company/industry/border information sharing is dependent upon uniform methodologies and practices.

FRCP changes and the impact on IT

Edward Liebig CISSP CISM CIPP — Fri, 20 Jul 2007 19:45:00 GMT

The “E-Discovery amendments” to the Federal Rules for Civil Procedure will have a significant impact on the practice of law. An early point made in “The Discovery Revolution” (Paul & Nearon, 2006). What I find interesting is that the seemingly simple rule change (as in Sarbanes Oxley) carries significant challenges to the information infrastructure and management requirements.

E-mail (archiving, search, retrieval and security) is just the tip of the iceberg. Multiply the requirements over all systems, file types, documents and in some cases database elements. The core elements of this process is only supported fully by a verbose, well embraced security program coupled with tools and process to support the identification, classification and lifecycle of information across an organization.

Point solutions alone may allow attorneys to sort through information but true management of the e-discovery capabilities and risks comes from proper infrastructure and information security program management.

The rule changes begin to recognize “electronically stored information” (ESI) and more importantly the “enveloping systems” as legal concepts. Rule 34 has been the long standing governance of the “Production of Documents and Things”. It has now stepped up to govern the “Production of Documents, Electronically Stored Information and Things”. This recognition opens new areas of responsibilities for attorneys and IT departments.

Attorneys have great expertise in the art of evidence handling but, let’s face it, IT people and process is rarely stringent enough to accommodate. By layering in a comprehensive security program complete with data lifecycle management the IT department turns from enslaved organization, charged with finding the information to the enabling group who makes e-discovery possible.

In preparation for a case litigants will need to examine both what they will and will not share between parties. This must be identified, documented and presented to the court within the first 99 days. The process begins by identifying the data and environment. Your legal department will ask you to:

1. Provide detailed description of computer systems used by the company, including hardware systems, primary operating systems, and major software systems, including any customized software.

2. Provide a detailed description of how those computers are networked or connected to others outside of the company (with a graphical representation if one is available).

3. Provide a detailed description of how your employees can network with your computers from outside of the company.

4. Provide a detailed description of the computer systems used by your employees outside of the corporate system (e.g., from home desktops or laptops, personal digital assistants [PDAs]).

5. Provide a detailed description of the backup processes and schedules, document retention and destruction schedules, organized by type of data. Identify the responsible persons for each process, with contact data. Identify storage locations for all backup data.

6. Provide the company’s document retention policy, e-mail, and Internet-usage policies and litigation-hold policy, to the extent they exist.

7. Describe any monitoring or logging of employees’ computer usage.

8. If any third parties hold or have access to the company’s data, identify those third parties with full contact information.

That seems easy… now they will want to move into the environment questions. They will ask you to provide…

1. The architecture and elements of the technology infrastructure, including, but not limited to, the amount and types of computers, operating systems, and software applications, including customized applications, with graphical representations if available.

2. The topology of the network environment, including, but not limited to, the physical placement of computers and their connectivity within the intranet and Internet, with graphical representations if available.

3. The architecture of the electronic mail system, including, but not limited to, server and workstation software and version, lists of users, and location of e-mail files.

4. Enterprise user information applications, including, but not limited to, contact lists, calendars, to-do lists, word processing, project management, and accounting.

5. Internal and external personnel responsible for the management and maintenance of the technology infrastructure and all of its components, with contact information.

6. Information about any business activity of employees that is not backed up by the company, including the use of home machines, laptops, PDAs, etc.

7. The names of all key players in any actual or potential lawsuit or investigation.

8. The names, addresses, and contact info for any third party that holds or has access to company data.

9. Backup policies and procedures, including, but not limited to, hardware and software used to back up and archive information, documentation of what data is backed up, backup schedules, and locations of all backup media devices.

10. Computer-use policies and procedures, including, but not limited to, employee guidelines, password use, system logging, security controls, data retention, litigation holds, information sharing, and acceptable Internet and electronic message usage.

11. The location and contents of any relevant system and event logs.

A little tougher but wait, there’s more - Now we dig into the actual evidence gathering:

These are simply the major components in the identification, isolation, evaluation, and preservation of electronic evidence and represent a standardized method that will be admissible in court. Other steps and/or technologies may be necessary...

1. Record each media device with a unique identifying number.

2. Write protect each media device.

3. Forensically duplicate each media device to create a true mirror image (note that this does not mean copying or "Ghosting").

4. Mathematically verify and validate that the mirror image is identical to the original by using hashing algorithms (MD5, SHA1, SHA2).

5. Scan media devices for viruses and spyware—document the results.

6. Produce directory structure for each media device.

7. Analyze the electronic media and extract relevant information.

8. Secure each media device.

The following is a list of places you attorneys will want to search for evidence:

Electronic evidence may reside in numerous different locations throughout an organization’s technology infrastructure, your legal team will want to dig into any/all/or even more than the following...

Electronic Information
1. Servers
2. Mainframes
3. Network file systems
4. Workstations
5. Laptop computers
6. Personal digital assistants (PDAs)
7. (Personal home computers
8. Private branch exchange (PBX)
9. Voice mail
10. Digital printers or copiers
11. Cell phones
Backup Media
1. Monthly systemwide backups
2. Weekly systemwide backups
3. Incremental systemwide backups
4. Unscheduled backups
5. Personal backups
Additional Media Devices
1. CD-ROMs
2. DVDs
3. Floppy diskettes
4. Zip disks
5. Tape archives
6. Removable hard drives
7. Thumb drives
8. Digital camera media

So, as you can see the e-discovery process will take a deep and broad look at your information technology environment and the data therewith in. Could you pull this together quickly? Waiting for litigation can be disastrous. Stay ahead of your legal communities expectations by calling an expert in information security, they can lead you to the tools and process necessary to smoothly integrate process, policy and technology to accommodate the challenge e-discovery brings.

Application Security in the SDLC

Edward Liebig CISSP CISM CIPP — Fri, 07 Jul 2006 11:09:00 GMT

Managers of application development and testing organizations must recognize security expertise/focus within their staff and invest in fostering an environment that embraces and rewards training, education, and processes for their respective teams. They must work with traditional security teams to understand what Application Development (AD) and Quality Assurance (QA) testing can do to alleviate security risks. At the earliest stages of the development project lifecycle, development managers should work with technology providers to understand the needs and requirements for building security into the application, and making security part of the entire life cycle approach. Managers must also assess the AD and QA testing organizations to determine whether security is strategic or viewed as an afterthought.

By 2009, 80 percent of companies will have suffered an application security incident, and, as a result, will react by creating roles in the AD and testing organizations to ensure that security considerations are addressed at the application level.

--- Gartner ---

Today's successful businesses know few boundaries and work seamlessly with customers, integrators, virtual teams, offshore providers, and trusted partners globally. Although networking and other security tools can curb most network penetrations, application-specific security tools can only offer limited protection for flawed applications. Reducing software flaws and improving security features (such as authentication) are the most-powerful tools to protect enterprise applications.

Application development (AD) and testing organizations must be proficient in creating, modifying, maintaining, and testing applications to deliver security as well as features and functionality. Security at the application level is a nascent area in which developers are rarely properly trained; however, technology providers are gearing up to assist businesses with the necessary skill growth.

Relying on training alone however is as foolish as relying on tools alone to remediate issues during the development or testing phases. Code reviews are simply only as good as the knowledge of the reviewer(s). Vulnerabilities are uncovered way to fast for any one developer or QA analyst to hope to keep up. Tools can update their knowledge closer to real time than any human could comprehend. Tools alone however cannot distinguish the reality of the discoveries nor assess risk based on the classification of the data or threat to the organization. Only a precision dance between tools and human intervention can produce a process that is manageable and scalable enough to achieve a quality level of necessary practice to safe guard the enterprise.

So, what is “Application Security”?
Application security involves developers creating secure source code to prevent the inclusion of potential security vulnerabilities, and involves test groups conducting vulnerability testing, application scanning and penetration testing to validate. Some of the most-common problems with source code that increase the risk of security vulnerabilities include:

• Buffer overflows

• Error handling

• Command injection

• Unnecessary code

• Malicious code

• Broken threads

• Invalidated parameters

• Cross-site scripting

• Caching, pooling and reuse errors

Application security focuses on three elements:

• Reducing security vulnerabilities and risks

• Improving security features and functions such as authentication, encryption or auditing

• Integrating with the enterprise security infrastructure

Although security represents many things to many people, the application has been primarily focused on features and functionality, and the market drivers are primarily time to market and cost. Security is another facet of quality — and like quality; security must be built into the application, not tested at the end of the development cycle. When confronted on security architecture question a developer will quickly state, “yes, the authentication and authorization parameters were gathered from the business requirements and worked into the overall design.” These parameters and issues however are only a part of application security. Looking at the languages and technologies used also carries right and wrong techniques to formulate code. The standards used should reflect generally accepted secure methods.

--- Gartner ---

Businesses have always been under threat of reliability and security events due to vulnerable source code. Although application outages are an unwelcome but inevitable event, an application outage caused by or coupled with a security violation is far more disastrous because of the loss of information, the difficulty in system recovery, lost productivity and so on. Part of the plan in building secure software is to make security part of the unified and comprehensive application life cycle. Having security at the start is crucial. Without skilled and trained professionals in the AD and testing groups, businesses will not build in security from the start and, as a result, security incidents will be far more likely.

The "last mile" in terms of security is the application. The best network, host, and data security cannot effectively protect a weak application. Security must be considered first in the application. This translates to planning for security in the application life cycle. AD and testing (process and application quality) organizations should heed the following action items:

• Develop a security strategy for AD and testing groups.

• Mandate security training for AD and testing staffs.

• Include security reviews in the development process as a codified set of behaviors.

• Perform a security review with the security team before development begins (that is, include the security team as a project stakeholder).

• Build security into project requirements (business and technical).

• Conduct security testing during development and use commercial tools (see "Stay Ahead of Changing Software Vulnerabilities").

• Require sign-off from the security team, just as you would from any other project stakeholder, before application deployment.

AD and testing organizations are responsible for building applications, and they must understand and implement security for the entire application. Whether it’s source code or an executable file, AD and testing organizations must identify where security defects or vulnerabilities are in the application.

It's been predicted that AD organizations would become extraneous due to outsourcing, the decreasing need to develop custom applications and the lack of technical capabilities. Those predictions have proved false, however, because AD and testing organizations provide significant value to how a business is run. Companies plan to ensure that events resulting from security incidents with applications never occur, and the AD and testing organizations will turn those plans into reality.

AD organizations are still building and maintaining code. Testing organizations are still responsible for process quality and application quality for custom code and packaged applications. AD and testing organizations, whether internal or outsourced, are essential to ensure that software is developed efficiently, effectively and securely.

Security is a new skill that AD and testing organizations must take on immediately. Training for security at the application level will happen on the job. However, few security professionals are proficient in the nuances of development, and few development professionals are proficient in the area of security. AD and testing organizations should invest in outside assistance to meet their application security needs. Prior to contracting with a professional service provider, AD and testing organizations should obtain references from similar customers, detail the scope of work and understand exactly what deliverables are expected. Professional service providers are likely to already have the much-needed security skills. If the AD and testing organization considers application security to be a strategic investment, then it should also invest in adequately training its AD and testing staffs. Combining on-the-job employee training with professional service providers is a reasonable way to achieve knowledge transfer. Today, fewer than 5 percent of IT organizations are actively working on application security

The application has always been a known security threat, but historically it has not received the attention required. In today's IT organization, new issues such as compliance, regulations, risk management, and ever-changing priorities are increasing the focus on application security. The boundaries between AD and operations, where security has primarily been a factor, must be shattered. Information plans and requirements regarding security must begin at the application level. Within AD and testing organizations, new roles with improved security skills will emerge. The application life cycle plays a significant role; it takes the emphasis away from AD (code creation) and places it squarely in the requirements phase. Improving security at the application level starts with the requirements phase. Teams can use popular business "storyboarding" products to build requirements for security, thereby demanding the creation of a test for that particular security requirement. The line of business that establishes the requirements must understand the consequences of failing to address security in the business requirements phase. The ideal scenario would be a consistent set of requirements across most projects, with increased levels of security in special cases. A process must also be built into the life cycle to establish requirements, test compliance and modify the base as new threats, tools or techniques become available

Today, developers are focused on building the right things at the right time for their customers. Organizations with a mature line of business will demand security from their applications. For the most part, testing is viewed as something conducted (if time permits) at the end of the development cycle. Because of the focus on time to market and doing more with less, primary test efforts have largely been focused on verifying functionality, not proactively investigating the potential effects of security defects. Tools, although not a panacea, have been focused on automation and productivity, not proactive analysis to prevent security incidents. Testing groups must be aware that security testing should focus on high fidelity (low false-alarm rate) tests. Approximately 20 percent of application security testing tool rules will find 80 percent of errors with low false-alarm rates. Going beyond that level will cause false positives that will frustrate developers, waste expensive development time and generally result in less security, not more. As the U.S. National Institute of Standards and Technology demonstrated in its May 2002 study, "The Economic Impacts of Inadequate Infrastructure for Software Testing," removing a software defect after a system is operational can cost two to five times more than if the defect was fixed during the final testing phase. This study emphasized that removing those defects during code and unit tests can reduce the cost impact by an additional factor of three to 20. Although defects ideally should be removed as early as the requirements analysis and architectural design phase, Gartner estimates that if 50 percent of software vulnerabilities were removed prior to production use for purchased and internally developed software, then enterprise configuration management costs and incident response costs would be reduced by 75 percent each.

The cost of fixing vulnerabilities and regression testing the repaired code can be reduced by a factor of at least three by detecting security errors during code and unit tests, compared with finding errors during integration tests. Detecting commonly made coding errors during this phase can also provide feedback to other modules that are still in the design and early-coding phases, so they can avoid repeating the same mistakes.

Throughout the application quality life cycle, risk is continuously assessed. Risk assessment is gaining information about security, performance, application metrics, service-level agreements and more, and turning that information into knowledge. The knowledge gained from ongoing risk analysis becomes the power to understand the application, to identify security vulnerabilities, to understand when an application will begin to degrade, and to stop an application from going into production

Highlights from the CSI/FBI Computer Crime and Security Survey

Edward Liebig CISSP CISM CIPP — Sun, 05 Feb 2006 04:35:00 GMT

The following is a reprint of the FBI posting outlining the highlights in the 2005 Computer Crime and Security Survey:

Thanks to the Computer Security Institute (CSI), we have some pretty good answers to that question.

Please read below for highlights from the 2005 CSI/FBI Computer Crime and Security Survey, based on responses from 700 U.S. corporations, government agencies, financial and medical institutions, and universities. This is our 10th annual survey in the information security field and, after reading it, we urge you to report to us any and all computer intrusions your company may experience.

1. Total financial losses from attacks have declined dramatically. Down 61% on a per-respondent basis from last year, but still reportedly $130M. What kinds of attacks? Virus attacks are #1; unauthorized access is #2; theft of proprietary information #3; and denial of service attacks a distant #4.

2. Attacks on computer systems or (detected) misuse of these systems have been slowly but steadily decreasing in all areas. Exception to the rule: a slight increase in the abuse of wireless networks.

3. Defacements of Internet websites have increased dramatically. 95% of organizations experienced more than 10 website incidents in 2004.

4. "Inside jobs" occur about as often as external attacks. The lesson is—anticipate attacks from all quarters.

5. Organizations largely defend their systems through firewalls, anti-virus software, intrusion detection systems, and server-based access control lists. Use of smart cards and other one-time password tokens increased, while use of intrusion prevention systems decreased.

6. More organizations are conducting security audits to serve as a baseline for a meaningful security program. 87% had conducted one.

7. Computer security investments per employee vary widely. State governments lead the pack at $497, followed, in descending order, by utilities, transportation, telecommuications, manufacturing, and high tech down to the federal goverment at $49.

8. Despite continuing discussion, there has been no increased use by organizations of outsourcing cybersecurity or using insurance to manage risks.

All good things to mull as you're reviewing your own computer network security. But please keep in mind we've only given you highlights. To get all the details, we encourage you to read the full report.

Resources: Computer Security Institute | FBI InfraGard program | Reporting Internet Crime | San Francisco FBI Computer Crimes

Welcome to CISO Today

Edward Liebig CISSP CISM CIPP — Sun, 05 Feb 2006 03:51:00 GMT

Hello and welcome to CISO Today. This has been a particularly difficult day as we found out my wife’s cousin was killed this past Thursday while serving in Iraq. I will not stoop to political “soap boxing” but I will say this… Insurgents – If you have an opinion on how to run your country and you firmly believe in your “cause” – Be Men. Show your face proudly. Walk among your peers with pride in your convictions. Don’t hide from your identity and take cowardice jabs at your opponent while wearing a hood over your face then slither to the darkness. Walt showed you his face.

OK back to the introductions

Book mark this site if you wish. I will post articles that cover issues that impact enterprise security. I’ll add tips for adding value to your organization with measurable results. Today however was not a good day for writing.

Support our troops, support our country, and support non-partisan patriotism.