<?xml version='1.0' encoding='UTF-8'?><rss xmlns:atom='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' version='2.0'><channel><atom:id>tag:blogger.com,1999:blog-7185731378551246027</atom:id><lastBuildDate>Tue, 29 Apr 2008 01:01:15 +0000</lastBuildDate><title>Red Light Security</title><description/><link>http://www.redlightsecurity.com/</link><managingEditor>Steven McElwee, CISSP</managingEditor><generator>Blogger</generator><openSearch:totalResults>29</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-898918706450493912</guid><pubDate>Tue, 29 Apr 2008 00:58:00 +0000</pubDate><atom:updated>2008-04-28T21:01:15.398-04:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Virtualization</category><title>Spinning Out of Control: Securely Managing Virtual Sprawl</title><atom:summary type='text'>Server virtualization is taking hold. It boasts so many advantages that it is likely to become the standard for data centers around the world. It saves money by maximizing hardware resources. It reduces the number of physical servers, which reduces power consumption. It also revolutionizes server deployment by allowing servers to be copied as easily as files on the file system. Add to this the </atom:summary><link>http://www.redlightsecurity.com/2008/04/spinning-out-of-control-securely.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-1563012877600896537</guid><pubDate>Thu, 17 Apr 2008 02:18:00 +0000</pubDate><atom:updated>2008-04-16T22:58:04.982-04:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Virtualization</category><title>Virtualization: Red Pill or Blue?</title><atom:summary type='text'>Virtualization technologies have been compared to the movie, The Matrix. In this, Neo and other humans, are captured in a virtual world. Neo is offered a blue pill or a red pill. The blue pill will return him to his normal unreal world in the matrix. The red will set his mind free by exposing the matrix. When it comes to virtualization technologies, the red pill and blue pill have similar </atom:summary><link>http://www.redlightsecurity.com/2008/04/virtualization-red-pill-or-blue.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-2258492525403911821</guid><pubDate>Sun, 13 Apr 2008 13:47:00 +0000</pubDate><atom:updated>2008-04-13T10:28:09.484-04:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Virtualization</category><title>Patch Management In a Virtual World</title><atom:summary type='text'>As more and more companies adopt virtualization in their data centers to reduce the number of physical servers and save money, security strategies need to be developed in parallel. While security may push back on this movement and resist its adoption, it will be far more beneficial to develop security strategies to deal effectively with advancing virtualization technologies.

Patch management is </atom:summary><link>http://www.redlightsecurity.com/2008/04/patch-management-in-virtual-world.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-1667508377851756975</guid><pubDate>Tue, 11 Mar 2008 22:37:00 +0000</pubDate><atom:updated>2008-03-11T19:02:44.115-04:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Six Sigma for Security, Part 5: Staying in Control</title><atom:summary type='text'>After you have moved through the define, measure, analyze, and improve stages of your Six Sigma for Security project, you are ready to move into the control phase. Your security operations should always operate in the control phase. If so, the control phase for Six Sigma is merely a matter of adding your improvements into your existing controls.

Here are some tools that you may find helpful in </atom:summary><link>http://www.redlightsecurity.com/2008/03/six-sigma-for-security-part-5-staying.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-3409058256914412681</guid><pubDate>Sat, 08 Mar 2008 21:45:00 +0000</pubDate><atom:updated>2008-03-08T17:16:03.621-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Six Sigma for Security, Part 4: Making Improvements</title><atom:summary type='text'>You have made your security program measurable. You have identified problem areas that keep you from meeting targets in your critical to quality (CTQ) goals. Now it is time to move on to making improvements and measuring their effectiveness.

One of the great things about Six Sigma is that improvements are tied to specific metrics, with a goal to reduce variation and improve your average. To make</atom:summary><link>http://www.redlightsecurity.com/2008/03/six-sigma-for-security-part-4-making.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-4373214918745434451</guid><pubDate>Fri, 07 Mar 2008 03:09:00 +0000</pubDate><atom:updated>2008-03-06T23:01:01.516-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Six Sigma for Security, Part 3: Analyzing the Data</title><atom:summary type='text'>Making security measurable is only the beginning of Six Sigma for Security. The purpose of security metrics is not the metrics themselves but what you do with them. The next phase is to analyze the data and find opportunities for improvement.

The analysis phase is what makes Six Sigma stand out. In it you will use statistics to find where you can make improvements. There are two improvements in </atom:summary><link>http://www.redlightsecurity.com/2008/03/six-sigma-for-security-part-3-analyzing.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-685587884650168120</guid><pubDate>Thu, 06 Mar 2008 02:26:00 +0000</pubDate><atom:updated>2008-03-05T22:20:10.134-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Six Sigma for Security, Part 2: Measuring</title><atom:summary type='text'>After you have defined the Critical to Quality (CTQ) goals of your security program, the next step is to determine how to measure them. Creating a measurement plan for security is like creating a scoreboard. It allows you to gauge at any time how successful you are and your level of protection.

Keep in mind that at the outset of this Six Sigma project we determined that we would not just measure</atom:summary><link>http://www.redlightsecurity.com/2008/03/six-sigma-for-security-part-2-measuring.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-5264607011024732873</guid><pubDate>Sun, 02 Mar 2008 00:27:00 +0000</pubDate><atom:updated>2008-03-02T17:25:07.173-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Six Sigma for Security, Part 1: Defining Success</title><atom:summary type='text'>How do you measure the effectiveness of your security program? Unlike business metrics which have tangible goals, such as revenue growth, inventory reduction, and sales force effectiveness, security's goal is to prevent internal and external breaches. Your goal in security should be to have nothing to measure - no virus attacks, no external breaches, no successful social engineering attacks, no </atom:summary><link>http://www.redlightsecurity.com/2008/03/six-sigma-for-security-part-1-defining.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-6510557424614684861</guid><pubDate>Sat, 01 Mar 2008 13:33:00 +0000</pubDate><atom:updated>2008-03-02T16:47:51.497-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Privacy</category><title>Privacy on the Web, Part 4: How to Hide from Web Beacons</title><atom:summary type='text'>Why would I want to hide from web beacons and consolidated web traffic analysis? I don't have anything to hide. We each make decisions about how much privacy and security to give up to gain convenience. The settings in web browsers - to save passwords, accept third party cookies, and keep authenticated sessions persistent over many days and across many sites - make using the web easier. For some </atom:summary><link>http://www.redlightsecurity.com/2008/03/privacy-on-web-part-4-how-to-hide-from.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-7104820343030888639</guid><pubDate>Wed, 06 Feb 2008 11:40:00 +0000</pubDate><atom:updated>2008-03-02T16:47:25.878-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Privacy</category><title>Privacy on the Web, Part 3: Analytics, Recommendations, Summarizing, and Anonymity</title><atom:summary type='text'>Since web beacons from outsourcing companies may be able to track your every move, you may wonder what they are doing with your information. This post discusses the positive side of collecting and using this information. It also touches on the issue of anonymity and privacy.

Analytics
If you are running a web site today, you are probably using some form of web analytics. From the multi-billion </atom:summary><link>http://www.redlightsecurity.com/2008/02/privacy-on-web-part-3-analytics.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-8860394597827585918</guid><pubDate>Tue, 05 Feb 2008 11:14:00 +0000</pubDate><atom:updated>2008-03-02T16:46:58.276-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Privacy</category><title>Privacy on the Web, Part 2: How Beacons Work</title><atom:summary type='text'>Web beacons are snippets of Javascript or HTML that create one pixel by one pixel image requests to a different web site that collects the data. This single pixel is invisible to the viewer of the web site. It is usually placed just inside the closing "body" tag of the page, although some analytics companies recommend that it be placed inside the opening "body" tag to improve accuracy.

There are</atom:summary><link>http://www.redlightsecurity.com/2008/02/privacy-on-web-part-2-how-beacons-work.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-57659467241077998</guid><pubDate>Mon, 04 Feb 2008 10:48:00 +0000</pubDate><atom:updated>2008-03-02T16:46:15.376-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Privacy</category><title>Privacy on the Web, Part 1: The Beacons Know You</title><atom:summary type='text'>Did you ever notice how a web site you have never visited before knows your interests enough to give you targeted advertisements? Sometimes, the ads are based on the content of the site, but other times, there appears to be no connection. There is an approach to collecting user information that crosses web site boundaries and maintains a history of your preferences.

You may ask, how is this </atom:summary><link>http://www.redlightsecurity.com/2008/02/privacy-on-web-part-1-beacons-know-you.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-1431381661840948167</guid><pubDate>Fri, 01 Feb 2008 11:11:00 +0000</pubDate><atom:updated>2008-03-02T16:45:31.231-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Security Process Maturity: Level 5</title><atom:summary type='text'>Security managers are often plagued by the question, “How do I make security measurable?” Since security does not produce a product or have a positive impact on the cash flow of a company, creating meaningful measurements that justify an organizations expenditure on security is challenging. This is where ISM3 provides a great tool for measuring security.

ISM3's level five is about taking all of </atom:summary><link>http://www.redlightsecurity.com/2008/02/security-process-maturity-level-5.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-8279307499924822114</guid><pubDate>Thu, 31 Jan 2008 11:30:00 +0000</pubDate><atom:updated>2008-03-02T16:43:42.497-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Security Process Maturity: Level 4</title><atom:summary type='text'>Level four of ISM3 adds the remaining security processes in the model. This level requires the highest investment, but provides the highest level of protection against technical and internal threats. The security processes in this level are necessary if your organization operates in a highly regulated environments with information assets that are targets for attackers. Examples include stock </atom:summary><link>http://www.redlightsecurity.com/2008/01/security-process-maturity-level-4.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-228876418663443418</guid><pubDate>Wed, 30 Jan 2008 11:18:00 +0000</pubDate><atom:updated>2008-03-02T16:42:53.324-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Security Process Maturity: Level 3</title><atom:summary type='text'>The third level of ISM3 requires significant investment, but it provides a high level of protection against technical security threats. This level is important for organizations that have high security risks and many critical assets, especially externally facing applications.

The jump from level two to level three does not add many processes, but the processes require more people and time </atom:summary><link>http://www.redlightsecurity.com/2008/01/security-process-maturity-level-3.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-3132052436203367236</guid><pubDate>Tue, 29 Jan 2008 11:45:00 +0000</pubDate><atom:updated>2008-03-02T16:42:24.577-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Security Process Maturity: Level 2</title><atom:summary type='text'>For most businesses, level one will not provide enough security to protect their information assets. If a company needs to demonstrate due care to its business partners, has many users of server-based applications, and sensitive information, it needs to move up to the security processes listed in ISM3's second level.

Level two provides additional protection against technical security threats. It</atom:summary><link>http://www.redlightsecurity.com/2008/01/security-process-maturity-level-2.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-1082571006704931093</guid><pubDate>Mon, 28 Jan 2008 10:45:00 +0000</pubDate><atom:updated>2008-03-02T16:41:54.087-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Security Process</category><title>Security Process Maturity: Level 1</title><atom:summary type='text'>How mature is security in your organization? Thanks to the ISM3 Consortium, we have a framework for measuring the security maturity of any organization. ISM3 looks at security as a set of defined processes. Each level of maturity has its own processes. Organizations can decide how much security is enough for their type of business and ensure that the processes at that level are defined and </atom:summary><link>http://www.redlightsecurity.com/2008/01/security-process-maturity-level-1.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-2809301779909008042</guid><pubDate>Fri, 25 Jan 2008 11:38:00 +0000</pubDate><atom:updated>2008-03-02T16:41:21.001-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 11: The Checklist</title><atom:summary type='text'>This post wraps up the series on secure coding practices. Remember that secure coding begins with having coding standards that are communicated to software engineers. Awareness of the secure coding practices alone will help improve the security of your software applications.

Next, remember that source code must be reviewed. This practice may be performed by software engineers, by a security </atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-11.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-1009163540635153108</guid><pubDate>Thu, 24 Jan 2008 14:56:00 +0000</pubDate><atom:updated>2008-03-02T16:40:42.515-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 10: Code Quality</title><atom:summary type='text'>Overall code quality is important for secure applications. Software bugs may create opportunities for attackers to exploit the application or gain information they should not have about system internals or even user credentials.

Security professionals may not know enough about the code they review to understand what is a defect and potential vulnerability. Some developers also overlook coding </atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-10-code.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-7854288078782357443</guid><pubDate>Wed, 23 Jan 2008 11:04:00 +0000</pubDate><atom:updated>2008-03-02T16:40:12.544-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 9: Performance</title><atom:summary type='text'>One of the security professional's concerns is the availability of systems. Although this may seem like the sole responsibility of the IT operations department, security assesses the risk to the availability of critical information assets. This is because attackers may not care about retrieving information or gaining access to your systems. They may simply want to attack your system to make it </atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-9.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-8055332195971336731</guid><pubDate>Tue, 22 Jan 2008 11:23:00 +0000</pubDate><atom:updated>2008-03-02T16:39:42.841-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 8: Cryptography</title><atom:summary type='text'>Several volumes can be written on encryption. With the various protocols and and approaches to encryption, it can leave software developers uncertain about how it applies to them.

Sensitive data must be encrypted. This may be to support compliance requirements, such as PCI and HIPAA, or it may be because your own organization has standards that require certain data to be encrypted. At a minimum,</atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-8.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-6032708227197566473</guid><pubDate>Mon, 21 Jan 2008 11:14:00 +0000</pubDate><atom:updated>2008-03-02T16:39:03.182-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 7: Error Handling</title><atom:summary type='text'>Error handling is important in software applications. For developers, it may be a necessary evil, but for security professionals, it is a vital part of maintaining confidentiality, integrity, and availability. Error handling, tied with appropriate logging, is also important for investigation of incidents.

One of the most important functions of error handling is that it must allow the application</atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-7-error.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-5045513334331144067</guid><pubDate>Fri, 18 Jan 2008 12:02:00 +0000</pubDate><atom:updated>2008-03-02T16:37:15.267-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 6: Logging</title><atom:summary type='text'>Logging is not always thought of as a security consideration, but it is important for on-going security monitoring. By logging events that help detect a security breach or attack, applications can provide early warning to security staff.

Although security monitoring may be out of scope for developing your application, the capability to log security events is important. Choose a commonly accepted</atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-6-logging.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-636238180141573693</guid><pubDate>Thu, 17 Jan 2008 11:01:00 +0000</pubDate><atom:updated>2008-03-02T16:36:45.328-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 5: Session Management</title><atom:summary type='text'>Session management security is especially important in web applications. A user can view and modify all information that is passed to and from a web browser. Popular browsers have plug-ins to make viewing and modification of HTTP traffic easy. As a result, the means of establishing, maintaining, and ending a session are in full view of the end user.

To make session management secure, it is </atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-5-session.html</link><author>Steven McElwee, CISSP</author></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-7185731378551246027.post-4872616002786271</guid><pubDate>Wed, 16 Jan 2008 11:40:00 +0000</pubDate><atom:updated>2008-03-02T16:36:09.930-05:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>Secure Coding Practices</category><title>Secure Coding Practices, Part 4: Data Validation</title><atom:summary type='text'>Data validation is one of the most important secure coding practices, since it is the most exploited function of applications. Whether your organization creates web applications, desktop applications, or client server systems, data validation is crucial to protecting the applications, data, and servers on which they reside.

The most important data to validate is data that has come from user </atom:summary><link>http://www.redlightsecurity.com/2008/01/secure-coding-practices-part-4-data.html</link><author>Steven McElwee, CISSP</author></item></channel></rss>