Research

‘I was a bit shocked to read about Adolf Merckle’s suicide yesterday. You just don’t see this sort of thing coming and I cannot even fathom the reasoning behind it. This has sent tremors through the market and certainly his holding company into dis-array for a while. It also reminded me of other similar events surrounding the last economic downturn , and that was kind of the ‘final straw’ that prompted this post. With many of the same signs and issues occurring as they did in the tech collapse of 2000-2002, few are eager to look at the downside, but it is time to spend a few minutes and verify contingency plans within your organization. It is a New Year, and what’s more a bright sunny day in Phoenix, so while it feels a bit incongruous to be talking about disaster recovery and such, it is a good time for you to give it a little thought. I am not really going into the issues of natural disaster, rather economic disaster. Nor am I focused on executives who need to consider change in management, but for the general well being of the people who work in your company whose livelihood and personal information may be dependent upon some degree of continuity. Files: Budget in advance for the storage of sensitive information. I am not just talking about electronic data, but all of the legal, contract, HR and other files that contain sensitive information. Pre-pay for files to be housed off site and stored safely. This is typically not that expensive, and in the event that the company changes hands or goes out of business, could become essential- but when the need is clear, it might already be too late. What you don’t want is contracts, accounting information, and employee files getting chucked in a dumpster. It happens, and it happened a lot in 2001, only this time there are regulatory fines if you get caught. If you are not doing this today, look into it. Many of the services provide destruction services at the end of term so the data is safely disposed of. Executive transition: Executives leave, and sometimes in unexpected ways. I am not trying to make fun here but point out that in stressful times, people look to change their situation. In tough economic climates, executives leave for what is perceived to be a safer place to work. As a board, HR department or executive team, think about the risks and have a basic plan of action in the event that any of the key staff leaves the company. Executive departure can stall incoming revenue, business partnerships, financing and even sale. There may not be a lot you can do, but better to be prepared. On-site and off-site backups: You are probably already doing this, so I will focus on an equally important issue: Verify your backups. In the tech collapse of 2001-2002, many firms went out of business without access to the data that formed the core business value. Backups could not be found or were unreadable. In many cases, their servers were ‘in hock’, locked up at the Colo facility with unpaid fees. This stalled the sale of assets and cost jobs that would have otherwise been offered had the data been available. So verify that the backups are complete and readable. If the backup are encrypted, make sure the key and de-cryption infrastructures is also available. Employees on Visas: I have seen some very uncomfortable moments for those employees on a Visa that are in a much more vulnerable situation. If this applies to you, go through a couple ‘what-if’ scenarios and have a plan to deal with the company shutting down, downsizing or being acquired. Press your HR team for assistance in this area. General Security: As a company begins to reduce staff, items walk out the door, from office supplies to computers. You really don’t want a laptop with customer data being sold on eBay, so you will want to tighten up on security. Physical security- make sure major assets are accounted for. Have your IT staff take inventory. Electronic security- Make sure you procedures are in place for shutting down accounts and snap-shotting the end point so there is no loss of data or correspondence. You may want to consider adding email filters to forward business related email, or re-routing telephone numbers. Startups: If you work for a startup, you want to take this advice a little more to heart. Startups by their very nature tend have less cash reserves, their margin for error is smaller, and their tolerance for both is higher. That means when things go bad, they do so very quickly. Most entrepreneurial CEO’s always figure the next deal is around the corner and are out of business the next day when it does not come. This leaves for some ugly exits where the employees do not get paid, benefits not covered and investors are wondering where all of the remaining assets are. If your revenues are not on the rise, then look for ways to cut costs at a company and individual level. Look to eliminate things you deem wasteful. Demand that management be forthright with you on what they are doing to cut costs and what a realistic run rate is. Set expectations with supervisors that you will be more tightly focus on priorities, but doing less with less. Without these steps, life devolves into a Dilbert cartoon. Personal Development: On a positive note, downturn s offer opportunity, and are a great time to expand your horizons. As companies try to perform the same functions with fewer resources, it is an opportunity to offer your assistance in areas you are interested in and broaden your skill set and increase your value. Education and training is also a great for this, providing a distraction form the daily grind and a good motivator as well. Try to contain your exposure to bad economic news if possible; I used

‘Whew! This is our final post in this series on Building a Web Application Security Program (Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7), and it’s time to put all the pieces together. Here are our guidelines for designing a program that meets the needs of your particular organization. Web application security is not a “one size fits all” problem. The risks, size, and complexity of the applications differ, the level of security awareness among team members varies, and most importantly the goals of each organization are different. In order to offer practical advice, we needed to approach program development in terms of typical goals. We picked three use cases to represent common challenges organizations face with web app security, and will address those use cases with appropriate program models. We discuss a mid-sized firm tackling a compliance mandate for the first time, a large enterprise looking to improve security across customer-facing applications, and a mid-to-large organization dealing with security for internal applications. Each perspective has its own drivers and assumptions, and in each scenario different security measures are already in place, so the direction of each program will be different. Since we’ve been posting this over a series of weeks, before you dig in to this post we recommend you review Part 4: The Web Application Security Lifecycle which talks about all tools in all phases. First we describe the environment for each case, then overall strategy and specific recommendations. Large Enterprise with Customer Facing Web Applications For our first scenario, let’s consider a large enterprise with multiple customer-facing web applications. These applications evolved to offer core business functions and are a principal contact point with customers, employees, and business partners. Primary business drivers for security are fraud reduction, regulatory compliance, and service reliability as tangible incentives. Secondary factors are breach preparedness, reputation preservation, and asset protection secondary – all considerations for security spending. The question is not whether these applications need to be secured, but how. Most enterprises have a body of code with questionable security, and let’s be totally honest here- these issues are flaws in your code. No single off-the-shelf product is going to magically make your application secure, so you invest not only in third-party security products, but also in improvements to your own development process which improve the product with each new release. We assume our fictitious enterprise has an existing security program and the development team has some degree of maturity in their understanding of security issues, but how best to address problems is up for debate. The company will already have a ‘security guy’ in place, and while security is this guy’s or gal’s job, the development organization is not tasked with security assessments and problem identification. Your typical CISO comes from a network security background, lacks a secure code development background, and is not part of this effort. We find their security program includes vulnerability assessment tools, and they have conducted a review of the code for typical SQL injection and buffer overflow attacks. Overall, security is a combination of a couple third-party products and the security guy pointing out security flaws which are patched in upcoming release cycles. Recommendations: The strategy is to include security within the basic development process, shifting the investment from external products to internal products and employee training. Tools are selected and purchased to address particular deficiencies in team skill or organizational processes. Some external products are retained to shield applications during patching efforts. Training, Education, and Process Improvements: The area where we expect to see the most improvement is the skill and awareness of the web application development team. OWASP’s top flaws and other sources point out issues that can be addressed by proper coding and testing … provided the team knows what to look for. Training helps staff find errors and problems during code review, and iteratively reduces flaws through the development cycle. The development staff can focus on software security and not rely on one or two individuals for security analysis. Secure SDLC: Knowing what to do is one thing, but actually doing it is something else. There must be an incentive or requirement for development to code security into the product, assurance to test for compliance, and product management to set the standards and requirements. Otherwise security issues get pushed to the side while features and functions are implemented. Security needs to be part of the product specification, and each phase of the development process should provide verification that the specification is being met through assurance testing. This means building security testing into the development process and QA test scenarios, as well as re-testing released code. Trained development staff can provide code analysis and develop test scripts for verification, but additional tools to automate and support these efforts are necessary, as we will discuss below. Heritage Applications: Have a plan to address legacy code. One of the more daunting aspects for the enterprise is how to address existing code, which is likely to have security problems. There are several possible approaches for addressing this, but the basic steps are 1) identification of problems in the code, 2) prioritization on what to fix, and 3) planning how to fix individual issues. Common methods of addressing vulnerabilities include 1) rewriting segments of code, 2) method encapsulation, 3) temporary shielding by WAF (“secure & patch”), 4) moving SQL processing & validation into databases, 5) discontinuing use of insecure features, and 6) introduction of validation code within the execution path. We recommend static source code analysis or dynamic program analysis tools for the initial identification step. These tools are cost-effective and suitable for scanning large bodies of code to locate common risks and programming errors. They detect and prioritize issues, and reduce human error associated with tedious manual scanning by internal or external parties. Analysis tools also help educate staff about issues with certain languages and common programming patterns. The resulting arguments over what to do with 16k insecure occurrences

Update: Some additional information was just posted on the Twitter Blog. Along with some comments on how their soon to be Beta ‘0auth’ would not have prevented this attack, there is also some information on the extent of the scam. Seems that Barack Obama’s account was hacked along with a few others. Did this strike anyone else as odd: if Obama has not been twittering since being elected, does that mean a staffer logged in on his behalf? An interesting note popped up on Twitter this morning about a Phishing attack through direct messages and direct email. The Phish is very well done and looks legit, so it will probably be effective. It is asking for you to provide access credentials to Twitter, but the domain is accesslogins.com. The WHOIS for Access-Logins shows it owned by XIN NET Technology Corp from Beijing, with all of the 126.com email accounts hosted from Netease.com. That’s a long way from San Francisco. Access-Logins is the home of a few dozen other Phishing sites, from McAfee to Defcon. Needless to say, don’t click on email links. The real question on my mind is: once you have clicked onto the Phishing login page, will Twitter’s real reset password function be vulnerable to an XSS attack? I do not have a copy of the original email so I am unable to test. If you fall victim to this you will want to clear all of your private data from the browser and restart it before trying to reset your password. Or shut down your current browser and use the password reset from a different one- otherwise other passwords may be captured as well. Share:

Macworld Expo may no longer be good enough for Apple, but it’s still one of my conference highlights of the year. I’ll be out there today through Thursday while Adrian manages the fort in Phoenix (I’ve managed to convince him that cleaning the cat litter while my wife is at work is a formal job responsibility, please don’t tell him that’s illegal and stuff). Most of my writing this week will be over at TidBITS, but I’ll pop some of my informal thoughts (and anything security related) over here at Securosis and on Twitter. And if any of you are over at the Expo, drop me a line and let’s try to meet up. For the record- I don’t expect any earth shattering new announcements this week, but some nice incremental upgrades. To be honest, I’d rather have better stability and functionality with what I already own than some new device I’ll get in trouble for buying. P.S. Dear Apple, if you do announce anything insanely new and cool, please make it small enough to fit in my carry-on luggage. That is all. Share: