Research

I have found a unique way to keep anyone from using my iMac. While family & friends love the display, they do not use my machine. Many are awed that they can run Windows in parallel to the Mac OS, and the sleek appearance and minimal footprint has created many believers- but after a few seconds they step away from the keyboard. Why? Because they cannot browse the Internet. My copy of Firefox has NoScript, Flashblock, cookie acknowledgement, and a couple of other security related ad-ons. But having to click the Flash logo, or to acknowledge a cookie, is enough to make them leave the room. “I was going to read email, but I think I will wait until I fly home”. I have been doing this so long I never even notice. I never stopped to think that every web page requires a couple extra mouse clicks to use, but I always accepted that it was worth it. The advantages to me in terms of security are clear. And I always get that warm glow when I find myself on a site for the first time and see 25 Flash icons littering the screen and a dozen cookie requests for places I have never heard of. But I recognize that I am in the minority. The added work seems to so totally ruin the experience and completely turn them off to the Internet. My wife even refused to use my machine, and while I think the authors of NoScript deserve special election into the Web Security Hall of Fame (Which given the lack of funding, currently resides in Rich’s server closet), the common user thinks of NoScript as a curse. And for the first time I think I fully understand their perspective, which is the motivation for this post. I too have discovered my tolerance limit. I was reading rsnake’s post on RequestPolicy Firefox extension. This looks like a really great idea, but acts like a major work inhibitor. For those not fully aware, I will simply say most web sites make requests for content from more than just one site. In a nutshell you implicitly trust more than just the web site you are currently visiting, but whomever provides content on the page. The plugin’s approach is a good one, but it pushed me over the limit of what I am willing to accept. For every page I display I am examining cookies, Flash, and site requests. I know that web security is one of the major issues we face, but the per-page analysis is not greater than the time I spend on many pages looking for specific content. Given that I do a large percentage of research on the web, visiting 50-100 sites a day, this is over the top for me. If you are doing any form of risky browsing, I recommend you use it selectively. Hopefully we will see a streamlined version as it is a really good idea. I guess the question in my mind is how much security will we tolerate? Even security professionals are subject to the convenience factor. Share:

It has been a very trying week, between all our current projects- both Rich and I have had untimely home repair work, Rich is recovering from the flu, and we are both scrambling to get work done before deadlines. We have been focused on a series for security spending justification, which we will be mostly posting in blog entries. This is one of the tougher projects I have ever worked on, especially when your goal is to provide pragmatic advice that does not require dusting off calculus. While I was never particularly comfortable with many of the economic models that have been bastardized adapted for security spending justification, I had never spent this much time examining them closely. Having now done so, wow, what a crock of s^&! ROI, NPV, IRR, ALE, ROSI: these things are worthless in terms of security justification. They just completely miss the concept of the value of information, and the careful balancing act between risk and security. Many concepts treated as orthogonal are not, and some of the loss calculations are non-linear. Typically half the relevant data cannot be quantified, and some is simply unavailable. I am happy to say that both Rich and I have had a few ‘ah ha!’ moments, and a few areas where we have disposed of some BS, and I look forward to posting and getting some comments on the subject. Most of the other stuff going on here at the Lane household is related to ergonomics and comfort. Since I returned from San Jose, it has felt like one long moving project. With more fu iture than could fit into two houses, let alone one, there was a lot of packing and organizing. Yes, it has been 6 months since I got back to Phoenix full time, and the move project is just now winding down. We packed the closets and third garage space with stuff, and gave away a lot as well. Slowly and surely we have rearranged the fu iture to make things comfortable. New desk, new computers, new chairs. And four years of back-logged home repair projects: “fix this, paint that, move everything around. No, move it back”. I can now say I feel like I am done, and I am finally concentrating on having a little fun. That is what got me started on the Music rant (see link below) about FM radio. I was trying to get music into the kitchen, the office and the car, which is when I was confronted with the hideous reality that is FM radio. So it is time to get a music server in the house, and transfer 500 or so CDs into Apple Lossless format. And then start the search for new music to fill it up, and find some online stations worth listening to. There was a LOT of interesting stuff in the news this week and we compiled a lot of links. Here is the week’s security summary: Webcasts, Podcasts, Outside Writing, and Conferences: In the Network Security Podcast this week, Martin & Rich discuss phishing, compliance costs, programming errors, and “How to suck at security”. Adrian quoted in eWeek article on DAM and SIEM integration. Rich’s TidBITS article on protecting yourself in Safari Favorite Securosis Posts: Rich: There are no Trusted Sites: Paris Hilton Edition. Adrian: So it has nothing to do with security, but this is still my favorite post this week. Time to shop for a music server. Favorite Outside Posts: Adrian: Martin’s PCI related blog list. Rich: This is a VERY impressive workflow for managing potentially controversial blog posts, and understanding the different categories of bloggers. I’m shocked this came out of the Air Force, not because they aren’t capable, but because it looks more attuned to the business world than the military. If you are a blogger, or work with bloggers, or read blogs, take the 2 minutes to read this. If you don’t fit any of those categories, what the hell are you doing on our blog? Get off our lawn! Top News and Posts: Very sneaky approach to capturing ATM pin numbers. Trolls suck; just because you wrote down an idea, filed some paperwork, then completely failed to actually do anything with it doesn’t mean you get to sue the world. Oh wait, I guess it does. Microsoft patches Windows. TJX Hackers gets 30 years in prison. How many of you, in your best ‘Spicoli’ voice, said “Awesome! Totally awesome!”. Just me? No, wait, Rothman did as well. Oracle Critical Patch Update for January 2009. Our comments here. You would never know it from looking at the Sana site, but AVG has acquired Sana Security. This is crazy: Countrywide execs mock their own ads. In court, no less. BitArmor’s latest PR bit. I admire their moxy, but they’re taking a serious gamble, both in PR and liability. Maltego 2 tutorial: Maltego is an information collection tool that absolutely rocks. If you ever want to track down the connections between people, systems, documents, and whatever: Maltego is your friend. PCI hits POS– It’s about freakin’ time. Gunnar’s 2009 to do list. Steve Jobs taking a leave of absence from Apple. This does not look good. Blog Comment of the Week: We did not get any security related comments this week, but we did get several good observations on music. Rob’s comment on Phil Collins is the Mel Torme of my generation: Radio? Are there still radio stations? I’m never out of internet range when I’m working, and if I’m not listening to my music I’m on Pandora (free subscription with my Squeezebox) or Radio Paradise. No commercials. Pandora does a good job of giving me the music I pick, and Radio Paradise has lots of good, new music. FM radio is so last century. 🙂 Now, time for a beer and a a few hours of frantic editing. Share:

Just finished a review of the Oracle January 2009 Critical Patch Update/advisory (CPU). There are two issues that you need to pay attention to with this release: If you are using Oracle Secure Backup or Weblogix Server plugins, you will want to download and patch ASAP. Here is why: In the former case, it appears that the Fortinet team discovered a few bugs within the Oracle Backup Server that can be exploited by buffer overflow, resulting in a server crash or worse. I have not seen any specific exploits for this, but I have heard that this could result in the hacker being able to execute arbitrary code on the backup server for the Windows platform. That is bad news as not only can you tapes be overwritten, but he backup server could be used to launch attacks against other services. I am making the assumption that you are blocking port 10,000, but regardless, patch ASAP. The second issue has to to with the Weblogic plug-in for Apache/IIS. I have asked a couple people if they understand the scope of the exploit, but none of my contacts know the specifics. If you know, please send me an email. As a matter of course I am really wary of threats to the web application stack as an attacker has many different methods to exercise vulnerabilities, and will, as soon as they learn about the vulnerability. If you are using the plug-in, patch ASAP. The core database server does not seem to suffer any significant vulnerabilities. One of the bugs that is patched allows a user to execute certain functions and circumvent the auditing functions, so if you are using Oracle’s native audit for regulatory efforts, or to seed a Database Activity Monitoring solution, consider the patch a little higher priority. Otherwise I recommend that you patch according to your established deployment cycles. Share:

This post is deeply off topic, has nothing to do with security, and everything to do with my personal realizations about music. My calendar says that it is 2009. My radio says it is 1978. The radio must be right because I just listened to ‘Warewolves of London’ each and every day for the last three days. It’s just weird, because I like music, but I am also getting tired of itl. I like to have the radio in the background pretty much all the time. I am what is called a ‘Stereophile’ as well. I love music and I love the intricacies of the technology used to reproduce music, so playing with stereo equipment is nirvana for me. When not writing white papers and blogging, I am reading about and listening to my stereo systems. 3 systems in all, plus a radio in the kitchen, car and garage. My musical tastes vary, but tend to listen to rock during the day, jazz/ragtime/blues at night. The latter has been great as I am not saturated with it, and I am constantly finding new stuff that I like (while I am on the subject, James Brown was a bad-ass!). But it’s the rock and roll on the Radio that’s got me really vexed. Why? On the Radio it is 1987. I know this because I have heard ‘Welcome to the Jungle’ each and every day for the last 8 days. Did our brains somehow imprint an image of what music was supposed to be when we were young, and now we cannot move away from that? It never thought as a child that when I became an adult I would be listening to the same music I was listening to at 4, 8, 12, 15, every day, day after day for eternity. Bad when you grow tired of songs you like, awful when you still hear the songs you grew weary of in high school. I always assumed that there would continually be new music that I liked, from the bands that I liked, and the radio stations would progress as the musicians did. Not so! AC/DC and Aerosmith may have the odd hit, most new music flops horribly. Chinese Democracy can’t get half the air time of Appetite for Destruction. Sure, that’s a blessing, but one is new and the other is a tired 22 years old. A couple new bands offer the interesting song or two, but the rock & roll stations continue to play the same music, over and over and over. It appears that every major rock band in the world wrote three songs and the reminder of their recordings were burned so that we could focus all our time and energy on a handful of ‘important’ (re: safe) songs. Oh, listen, it’s Aqualung. Just like yesterday. This is what prompted me to try and diversify from Rock a bit, but with very little success. Old school Hip Hop gets my occasional attention when I run across something like ‘You Be Illin’, but I have never been able to really enjoy Rap. Tried real hard with classical; even accepted the 1200 classical albums to see if my musical tastes somehow ‘matured’ enough to listen to these composers. Boredom forced me to give the collection away to someone who would appreciate it. Country and Western makes me feel like life is not worth living and I want to slash my wrists. There are plenty of popular mexican music stations that are somewhat entertaining, but after a while, especially when you do not understand the words, the same ‘da da da dat dat dah’ accordion bridge grows very fatiguing. So I tune back to one of the 6 rock stations I get here in Phoenix, where it’s 1985, and I am listening to this fresh cut of Sussudio. In my teens I would never have dreamt that Phil Collins would be on the radio, every day, as if he was a first run artist that everyone listed to – with a new top 10 hit every week. But just listen a few minutes and there he is, as if we just loved his stuff. He gets more air time than Kanye West. A competent singer, songwriter & drummer, I really have no problem with Phil Collins. OK to listen to, say, once a month. 4 times a day on the radio makes me want to hurl. And now I know why Phil Collins is the Mel Torme of my generaiton. Good enough to make the favored radio station play list, but if you were a non-fan of the art, you would think this guy is a Louis Armstrong or Mozart-esque musical genius. What can you do? Keep singing along I guess … “Aaahoo, Werewolves of London”. At least I LIKE that song. Share:

Here it is, our first Friday Summary of 2009. While it’s Adrian’s week to put the summary together, we thought it would be better if I handled the intro since I was at Macworld looking at cool stuff all week while he was manning the fort and cleaning my gutters (if he ever reads his employment contract, I’m totally screwed). Last year was my first Macworld, and I feel lucky I got to see the Great Jobsness give a keynote before he decided to take a break. Phil Shiller did a great job, there just wasn’t that much to announce; even without Jobs, these are still the best product announcement sessions I’ve ever seen. As for the products, I think Apple is hitting a home run with the iLife changes- the power in iPhoto and iMovie is just sturn ing. But if you want to read about this stuff, head over to our TidBITS coverage. On the security front I saw two really interesting things I’d like to award with the Securosis Best of Macworld Expo. First up is Agile Software for 1Password. They win for 2 reasons- first is that they decided to cancel My1password.com. The idea was to build a web application for password management you could access from anywhere. If you read this site, you know the difficulties in such as risky move. Instead they are leveraging DropBox and letting you move passwords via USB storage. Yes, there are still risks, but it’s a granular system and sometimes we really do need to move passwords around with us. The second reason is the upcoming 3.0 version of the product. It’s polished, secure, useful, and one of those tools I use daily. Our second winner is Checkpoint for a pre-alpha version of the iPhone VPN client. They added an option so that when you go to connect it sends a text message to your phone with a one time password. Sure, this has been done before, but on the iPhone the VPN client automatically picks the password out of the text message and logs you in… no manual cutting and pasting or anything. Which is good, because you sort of can’t cut and paste on the iPhone. I saw a lot of other really great stuff, and quite enjoyed the usual evening activities. Macworld is a lot less crazy than our security conferences, so Amrit Williams and Adam O’Do ell came out to spice things up, and Amrit ran into Raffi while parking his car. Who says Mac users hate security! (Then again, I was buying, which might explain a few things). On that note, it’s time to catch up on massive amounts of email and turn the Summary back over to Adrian for all the security news I missed… Here is the week’s security summary: Webcasts, Podcasts, Outside Writing, and Conferences: The Network Security Podcast this week was a little shorter with Rich being at Moscone Center and Martin needing to spend time with the family, but they covered some good stuff with a discussion on 0Auth, weak passwords, the Phishing attack on Twitter users and facial recognition in iPhoto. Rich has a nice writeup of the new MacBook Pro on Tidbits. Favorite Securosis Posts: Rich: Part 8 of Building a Web Application Security Program is a great ending to the series. Adrian: Contingency Plans: The tech collapse took its toll on me, but I learned a lot, and hopefully there might be some advice you find helpful during this go-round. Favorite Outside Posts: Adrian: Robert Graham’s post on Verisign’s Response to the MD5 cert problem is a good analysis of the situation and how Verisign responded. It’s a bad sign when a company fails to defend its core business and then reacts in this manner when issues are pointed out. Rich: Crazy Apple Rumors site: “The best Keynote Liveblog ever!” Top News and Posts: Twitter Phish reported this week. Social engineering gets better and it becomes increasingly difficult to tell a real from fake without close inspection. MacWorld with week, with a nice, shiny new MacBook Pro announced. Life parodies itself, with CheckFree having a breach of 5M records. Unemployment is officially listed at 7.2% nationally. Here in AZ, our state is telling us it is still around 6.8%, but I am willing to bet that it is closer to double that number. TJX Hacker gets 30 years. More and more fake shopping sites popping up. Blog Comment of the Week: windexh8er on Part 7, Secure Operations: Great series guys! I was just playing around with NSMnow! — so the content in the monitoring portion was fresh in my mind. Maybe look to include a tools list in your next post where you talk about balancing the program. http://www.securixlive.com/nsmnow/index.php   Which is one of our recommendations in part 8 … we’ll also do a ‘recommended free tools’ post in the coming weeks. Share:

‘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:

We’ve been covering a heck of a lot of territory in our series on Building a Web Application Security Program (see Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6). So far we’ve covered secure development and secure deployment, now it’s time to move on to secure operations. This is the point where the application moves out of development and testing and into production. Keep in mind that much of what we’ve talked about until now is still in full effect- just because you have a production system doesn’t mean you throw away all your other tools and processes. Updates still need to go through secure development, systems and applications are still subject to vulnerability assessments and penetration testing (although you need to use a different process when testing live applications vs. staging), and configuration management and ongoing secure management are more important than ever before. In the secure operations phase we add two new technology categories to support two additional processes- Web Application Firewalls (WAF) for shielding from certain types of attacks, and monitoring at the application and database levels to support auditing and security alerting. Before we dig in, we also want to thank everyone who has been commenting on this series as we post it- the feedback is invaluable, and we’re going to make sure everyone is credited once we put it into whitepaper format. Web Application Firewalls (WAF) The role of a web application firewall is to sit in front of or next to a web application, monitoring application activity, and alerting or blocking on policy violations. Thus it potentially serves two functions- as a detective control for monitoring web activity, and as a preventative control for blocking activity. A web application firewall is a firewall specifically built to watch HTTP requests and block those that are malicious or don’t comply with specific rules. The intention is to catch SQL injection, Cross Site Scripting (XSS), directory traversal, and various HTTP abuses, as well as authorization, request forgeries, and other attempts to alter web application behavior. The WAF rules and policies are effectively consistency checks, for both the HTTP protocol and application functionality. WAFs can alert or block activity based on general attack signatures (such as a known SQL injection attack for a particular database), or application-specific signatures for the web application being protected. WAF products examine inbound and outbound HTTP requests, compare these with the firewall rules, and create alerts for conditions of concern. Finally, the WAF selects a disposition for the traffic: 1) let it pass, 2) let it pass but audit, 3) block the transaction, or 4) reset the connection. WAFs typically network appliances. They are normally placed in-line as a filter for the application (proxy mode); or ‘out-of-band’, receiving traffic from a mirror or SPAN port. In the former scenario, all inbound and outbound requests are intercepted and inspected prior to the web server receiving the request or user receiving the response, reducing load on the web application. For SSL traffic, inline WAFs also need to proxy the SSL connection from the browser so it can decrypt and inspect traffic before it reaches the web server, or after it leaves the web server for responses. In out-of-band mode, there are additional techniques to monitor the encrypted connections by placing a copy of the server certificate on the WAF, or positioning it behind an SSL concentrator. Some vendors also provide WAF capabilities via plug-ins for specific platforms, rather than through external devices. The effectiveness of any WAF is limited by the quality of the policies it is configured to enforce. Policies are important not merely to ability to recognize and stop known/specific attacks, but also for flexibly dealing with ambiguous and unknown threat types, while keeping false positives manageable and without preventing normal transaction processing. The complexity of the web application, combined with the need for continuous policy updates, and the wide variety of deployment options to accommodate, pose a complex set of challenges for any WAF vendor. Simply dropping a WAF in front of your application and turning on all the default rules in blocking mode is a recipe for disaster. There is no way for black box to effectively understand all the intricacies of a custom application, and customization and tuning are essential for keeping false positives and negatives under control. When deployed in monitoring mode, the WAF is used in a manner similar to an intrusion detection system (IDS). It’s set to monitor activity and generate alerts based on policy violations. This is how you’ll typically want to initially deploy the WAF, even if you plan on blocking activity later. It gives you an opportunity to tune the system and better understand application activity before you start trying to block connections. An advantage of monitoring mode is that you can watch for a wider range of potential attacks without worrying that false positives will result in inappropriate blocking. The disadvantages are 1) your incident handlers will spend more time dealing with these incidents and false positives, and 2) bad activity won’t be blocked immediately. In blocking/enforcement mode, the WAF will break connections by dropping them (proxy mode) or sending TCP reset packets (out of band mode) to reset the connection. The WAF can then ban the originating IP, permanently or temporarily, to stop additional attacks from that origin. Blocking mode is most effective when deployed as part of a “shield then patch” strategy to block known vulnerabilities in your application. When a vulnerability is discovered in your application, you build a specific signature to block attacks on it and deploy that to the WAF (the “shield”). This protects your application as you go back and fix the vulnerable code, or wait for an update from your software provider (the “patch”). The shield then patch strategy greatly reduces potential false positives that interfere with application use and improves performance, but is only possible when you have adequate processes to detect and evaluate these vulnerabilities. You can combine both

A Microsoft Security Advisory for SQL Server (961040) was posted on the 22nd of December. Microsoft has done a commendable job and provided a lot of information on this page, with a cross reference of the CVE number (CVE-2008-4270) so you can find more details if you need it. Any stored procedure that provide remote code execution can be dangerous and is a target for hackers. You want to patch as soon as Microsoft releases a patch. Microsoft states that “… MSDE 2000 or SQL Server 2005 Express are at risk of remote attack if they have modified the default installation to accept remote connections, if they allow untrusted users access to MSDE 2000 or SQL Server 2005 Express …” But I rate the risk higher than they say because of the following: MSDE 2000 and SQL Server Express 2005 are often bundled/embedded into applications and so their presence is not immediately apparent. There may be copies around that IT staff are not fully aware of, and/or these applications may be delivered with open permissions because the developer of the application was not concerned with these functions. Second, replication is an administrative function. sp_replwritetovarbin, along with other stored procedures like sp_resyncexecutesql and sp_resyncexecute, functions run as DBO, or Database Owner, so if they are compromised they expose permissions as well as functions. Finally, as MSDE 2000 and SQL Server Express 2005 get used by web developers who run the database on the same machine with the same OS/DBA credentials, you server could be completely compromised with this one. So follow their advice and run the command: use master deny execute on sp_replwritetovarbin to public” A couple more recommendations, assuming you are a DBA (which is a fair assumption if you are running the suggested workaround) check the master.dbo.sysprotects and master.dbo.sysobjects for public permissions in general. Even if you are patched for this specific vulnerability, or if you are running an unaffected version of the database, you should have this procedure locked down otherwise you remain vulnerable. Over and above patching the known servers, if you have a scanning and discovery tool, run a scan across your network for the default SQL Server port to see if there are other database engines. That should spotlight the majority of undocumented databases. Share: