Securosis

Research

RSA Treks to Sherwood Forest and Buys the Archer

EMC/RSA announced the acquisition of Archer Technologies for an undisclosed price. The move adds an IT GRC tool to EMC/RSA’s existing technologies for configuration management (Ionix) and SIEM/Log Management (EnVision). Though EMC/RSA’s overall security strategy remains a mystery, they claim to be driving towards packaging technologies to solve specific customer use cases – such as security operations, compliance, and cloud security. This kind of packaging makes a lot of sense, since customers don’t wake up and say “I want to buy widget X today” – instead they focus on solving specific problems. The rubber meets the road based on how the vendor has ‘defined’ the use case to suit what its product does. Archer as an IT GRC platform fills in the highest level of the visualization by mapping IT data to business processes. The rationale for EMC/RSA is clear. Buying Archer allows existing RSA security and compliance tools, as well as some other EMC tools, to pump data into Archer via its SmartSuite set of interfaces. This data maps to business processes enumerated within Archer (through a ton of professional services) to visualize process and report on metrics for those processes. This addresses one of the key issues security managers (and technology companies) grapple with: showing relevance. It’s hard to take security data and make it relevant to business leaders. A tool like Archer, properly implemented and maintained, can do that. The rationale for Archer doing the deal now is not as clear. By all outward indications, the company had increasing momentum. They brought on Bain Capital as an investor in late 2008, and always claimed profitability. So this wasn’t a sale under duress. The Archer folks paid lip service to investing more in sales and marketing and obviously leveraging the EMC/RSA sales force to accelerate growth. The vendor ranking exercises done by big research also drove this outcome, as Archer faced an uphill battle competing against bigger players in IT GRC (like Oracle) for a position in the leader area. And we all know that you need to be in the leader area to sell to large enterprises. Ultimately it was likely a deal Archer couldn’t refuse, and that means a higher multiple (as opposed to lower). The deal size was not mentioned, though 451 Group estimates the deal was north of $100 million (about 3x bookings) – which seems too low. Customer Impact IT GRC remains a large enterprise technology, with success requiring a significant amount of integration within the customer environment. This deal doesn’t change that because success of GRC depends more on the customer getting their processes in place than the technology itself working. Being affiliated with EMC/RSA doesn’t help the customer get their own politics and internal processes in line to leverage a process visualization platform. Archer customers see little value in the deal, and perhaps some negative value since they now have to deal with EMC/RSA and inevitably the bigger organization will slow innovation. But Archer customers aren’t going anywhere, since their organizations have already bet the ranch and put in the resources to presumably make the tool work. More benefit accrues to companies looking at Archer, since any corporate viability concerns are now off the table. Users should expect better integration between the RSA security tools, the EMC process automation tools, and Archer – especially since the companies have been working together for years, and there is already a middleware/abstraction layer in the works to facilitate integration. In concept anyway, since EMC/RSA don’t really have a sterling track record of clean and timely technology integration. Issues As with every big company acquisition, issues emerge around organizational headwinds and channel conflict. Archer was bought by the RSA division, which focuses on security and sells to the technology user. But by definition Archer’s value is to visualize across not just technology, but other business processes as well. The success of this deal will literally hing on whether Archer can “break out” of the RSA silo and go to market as part of EMC’s larger bag of tricks. Interestingly enough, back in May ConfigureSoft was bought by the Ionix group, which focuses on automating IT operations and seemed like a more logical fit with Archer. As a reminder to the hazards of organizational headwinds, just think back to ISS ending up within the IBM Global Services Group. We’ll be keeping an eye on this. Issues also inevitably surface around channel conflict, especially relative to professional services. Archer is a services-heavy platform (more like a toolkit) that requires a significant amount of integration for any chance of success. To date, the Big 4 integrators have driven a lot of Archer deployments, but historically EMC likes to take the revenue for themselves over time. How well the EMC field team understands and can discuss GRC’s value will also determine ongoing success. Bottom Line IT GRC is not really a market – it’s the highest layer in a company’s IT management stack and only really applicable to the largest enterprises. Archer was one of the leading vendors and EMC/RSA needed to own real estate in that sector sooner or later. This deal does not have a lot of impact on customers, as this is not going to miraculously result in IT GRC breaking out as a market category. The constraint isn’t technology – it’s internal politics and process. We also can’t shake the nagging feeling that shifting large amounts of resources away from security and into compliance documentation may not be a good idea. Customers need to ensure that any investment in a tool like Archer (and the large services costs to use it) will really save money and effort within the first 3 years of the project, and is not being done to the exclusion of security blocking and tackling. The truth is it’s all too easy for projects like this to under-deliver or potentially explode – adding complexity instead of reducing it – no matter how good the tool. Share:

Share:
Read Post

Introducing Securosis Plus: Now with 100% More Incite!

I’m incredibly excited to finally announce that as of today, Mike Rothman is joining Securosis. This is a full merger of Security Incite and Securosis, and something I’ve been looking forward to for years. Back when I started the Securosis blog over 3 years ago I was still an analyst at Gartner and was interested in participating more with the open security community. A year later I decided to leave Gartner and the blog became my employer. I wasn’t certain exactly what I wanted to do, and was restricted a bit due to my non-compete, but I quickly learned that I was able to support myself and my family as an independent voice. Mike was running Incite at the time, and seeing him succeed helped calm some of my fears about jumping out of a stable, enjoyable job. Mike also gave me some crucial advice that was incredibly helpful as I set myself up. One of my main goals in leaving Gartner was to gain the freedom to both participate more with, and give back to, the security community. Gartner was great, but the nature of its business model prevents analysts from giving away their content to non-clients, and restricts some of their participation in the greater community. It’s also hard to perform certain kinds of primary research, especially longer-term projects. Since I had a non-compete, I sort of needed to give everything away for free anyway. Things were running well, but I was also limited in how much I could cover or produce on my own. I may have published more written words than any other security analyst out there (between papers and blog posts), but it was still a self-limiting situation. Then about 18 months ago Adrian joined and turned my solo operation into an actual analyst firm. At the same time Mike and I realized we shared a common vision for where we’d like to take the research and analysis game, and started setting up to combine operations. We even had a nifty company name and were working on the nitty-gritty details. When we had our very first conversation about teaming up, Mike told me there was only one person he’d work for again, but there wasn’t anything on the radar. Then, of course, he got the call right before we wrote up the final paperwork. We both saw this as a delay, not an end, and the time is finally here. This is exciting to me for multiple reasons. First, we now gain an experienced analyst who has been through the wringer with one of the major firms (Meta), thrived as an independent analyst, and fought it out on the mean streets of vendor-land. There aren’t many great analysts out there – and even fewer with Mike’s drive, productivity, experience, and vision. This also enables us to create the kind of challenging research environment I’ve missed since leaving Gartner. With Mike and our Contributors (David Mortman, David Meier, and Chris Pepper) we now have a team of six highly-opinionated and experienced individuals ready to challenge and push each other in ways simply not possible with only 2-3 people. Mike also shares my core values. Everything we write is for the end user, no matter the actual target audience. We should always give away as much as possible for free. We should conduct real primary research, as opposed to merely commenting on the world around us. Everything we produce should be pragmatic and help someone get their job done better and faster. Our research should be as objective and unbiased as possible, and we’ll use transparency and our no-BS approach as enforcement mechanisms. Finally, we’re lifers in the security industry – this is a lifestyle business, not a get-rich-quick scheme. This is also an amazing opportunity to work closely with one of the people I respect most in our industry. Someone I’ve become close friends with since first meeting on the rubber-chicken circuit. In our updated About section and the Merger FAQ, there’s a lot of talk about all the new things this enables us to do, and the additional value for our supporters and paying clients. But to me the important part is I get to work with someone I like and respect. Someone I know will push me like few others out there. Someone who shares my vision, and is fun to work with. The only bad part is the commute. It’s going to be a real bi%^& to fly Mike out to Phoenix for Happy Hour every week. Share:

Share:
Read Post

Mike Rothman Joins Securosis

Technology start-ups are unique organisms that affect employees very differently than other types of companies. Tech start-ups are about bringing new ideas to market. They are about change, and often founded on an alternative perspective of how to conduct business. They are more likely to leverage new technologies, hire unique people, and try different approaches to marketing, sales, and solving business problems. People who work at start-ups put more of themselves into their jobs, work a little harder, and are more impassioned about achievement and success. The entire frenetic experience is accelerated to the point where you compress years into months, providing an intimate level of participation not available at larger firms – the experience is addictive. When technology start-ups don’t succeed (the most common case), they take a lot out of their people. Failures result in layoffs or shutdown, and go from decision to unfortunate conclusion overnight. The technology and products employees have been pouring themselves into typically vanish. That’s when you start thinking about what went right and what went wrong, what worked and what didn’t. You think about what you would do differently next time. That process ultimately ends with some pent-up ideas and frustrations which – if you let them eat at you – eventually drive you back into the technology start-up arena. It took me 12 years and 5 start-ups to figure out that I was on a merry-go-round without end, unless I made the choice to step off and be comfortable with my decision. It took significant personal change to accept that no matter how good the vision, judgement, execution, and assembled team were, success was far from guaranteed. Where am I going with this? As you have probably read by now, 18 months ago Rich Mogull, Mike Rothman, and I planned a new IT research firm. Within a few weeks we got the bad news: Mike was going to join a small security technology company to get back on the merry-go-round. From talking with Mike, I knew he had to join them for all the reasons I mentioned above. I could see it in his face, and in the same position I would have done exactly the same thing. Sure, Securosis is a technology start-up as well, but it’s different. While hopeful Mike would be back in 24 months, I could not know for certain. If you are a follower of the Securosis blog, you have witnessed the new site launch in early 2009 and seen our project work evolve dramatically. Much of this was part of the original vision. We kept most of our original plans, jettisoned a few, streamlined others, and moved forward. We found some of our ideas just did not work that well, and others required more resources. We have worked continuously to sharpen our vision of who we are and why we are different, but we have a ways to go. I can say both Rich and I are ecstatic to have Mike formally join the team. It’s not change in my mind, but rather empowerment. Mike brings skills neither of us possesses, and a renewed determination that will help us execute on our initial vision. We will be able to tackle larger projects, cover more technologies, and offer more services. Plus I am looking forward to working with Mike on a daily basis! This is a pretty big day for us here, and thought it appropriate to share some of the thoughts, planning, and emotions behind this announcement. Share:

Share:
Read Post

Securosis + Security Incite Merger FAQ

What are you announcing? Today, we are announcing that Mike Rothman is joining Securosis as Analyst/President (Rich remains Analyst/CEO). This is a full merger of Securosis and Security Incite. Why is this a good move for Securosis? Not to sound trite, but bringing on Mike is a no-brainer. This immediately and significantly broadens Securosis’ coverage and positions us to grow materially in ways we couldn’t do without another great analyst. There are very few people out there with Mike’s experience as an independent analyst and entrepreneur. Mike proved he could thrive as a one-man operation (his jump to eIQ wasn’t a financial necessity), completely shares our values, and brings an incredible range of experience to the table. Those who read our blog and free research reports gain additional content in areas we simply couldn’t cover. Mike will be leading our network and endpoint security coverage, as well as bringing over the Pragmatic CSO (sorry, you still have to pay for it) and the Daily Incite (which we’re restructuring a bit, as you’ll see later in this FAQ). Given Rich and Adrian’s coverage overlap, adding Mike nearly doubles our coverage… with our contributors (David Mortman, Dave Meier, and Chris Pepper) rounding us out even more. Mike is also a “high producer”, which means we’ll deliver even more free content to the community. Our existing clients now gain access to an additional analyst, and Mike’s clients now gain access to all of the Securosis resources and people. Aside from covering different technical areas, Mike brings “in the trenches” strategy, marketing, and business analysis experience that neither Rich nor Adrian have, as they specialize more on the tech side. In terms of the company, this also allows us to finally execute on the vision we first started building 18 months ago (Securosis has been around longer, but that’s when we came up with our long-term vision). As we’ll discuss in a second, we have some big plans for new products, and we honestly couldn’t achieve our goals without someone of Mike’s experience. Why is this a good move for Security Incite and Mike Rothman? Mike digs a lot deeper into his perspectives in a POPE (People, Opportunity, Product, Exit) analysis, but basically there was a limitation in the impact Mike could have and what he could do as a solo practitioner. Finding kindred spirits in Rich and Adrian enables us to build the next great IT research firm. This, in turn, is a prime opportunity to build products targeting a grossly underserved market (mid-market security and IT professionals), while continuing to give back to the community by publishing free research. This allows Mike to get back to his roots as a network security analyst and enables Securosis to provide full and broad coverage of all security and compliance topics, which benefits both end user and vendor clients. But mostly it’s as Rich said: a great opportunity to work with great guys and build something great. What is the research philosophy of Securosis? Will that change now that Mike Rothman is part of the team? Securosis’ core operating philosophy is Totally Transparent Research. That says it all. Bringing Mike to the team doesn’t change a thing. In fact, he wouldn’t have it any other way. As Mike has produced (as a META analyst) and bought (as a vendor) “mostly opaque” research from the big research shops, he certainly understands the limitations of that approach and knows there is a better way. Who is your target customer? Securosis will target mid-market security and IT professionals. These folks have perhaps the worst job in IT. They have most of the same problems as larger enterprises, but far fewer resources and less funding. Helping these folks ensure and accelerate the success of their projects is our core objective for new information products and syndicated research offerings in 2010. Will all the research remain free and available on the Securosis blog? Yes, all of the Securosis primary research will continue to be published on the blog. Our research may be packaged up and available in document form from our sponsors, but the core research will always appear first on the blog. This is a critical leg of the Totally Transparent Research model. Our community picks apart our research and makes it better. That makes the end result more actionable and more effective. What kind of information products are you going to produce? We’re not ready to announce our product strategy quite yet, but suffice it to say we’ll have a family of products designed to accelerate security and compliance project success. The entry price will be modest and participating in a web-based community will be a key part of the customer experience. What about the existing retainer clients of Securosis? How will they be supported? Securosis will continue to support existing retainer customers. We’ve rolled out a new set of retainer packages for clients interested in an ongoing relationship. All our analysts participate in supporting our retainer clients. What’s going to happen to the Daily Incite? The Daily Incite is becoming the Securosis Incite and will continue to provide hard-hitting and hopefully entertaining commentary on the happenings in the security industry. Now we have 6 contributors to add their own “Incite” to the mix. We are also supplementing the Incite with other structured weekly blog posts including the “Securosis FireStarter,” which will spur discussion and challenge the status quo. We’ll continue producing the Securosis Weekly Summary to keep everyone up to date on what we’ve been up to each week. What about the Pragmatic CSO? The Pragmatic CSO is alive and well. You can still buy the book on the website and that isn’t changing. You may have noticed many of the research models Securosis has rolled out over the past year are “Pragmatic” in both name and nature. That’s not an accident. Taking a pragmatic approach is central to our philosophy of security and the Pragmatic CSO is the centerpiece of that endeavor. So you can expect lots more Pragmatism from Securosis over the coming years.

Share:
Read Post

Password Policy Disclosure

I am no fan of “security through obscurity”. Peer review and open discourse on security have proven essential in development of network protocols and cryptographic algorithms. Regardless, that does not mean I choose to disclose everything. I may disclose protocols and approach, but certain details I choose to remit. Case in point: if I were Twitter, and wanted to reduce account hijacking by ridding myself of weak passwords which can be easily guessed, I would not disclose my list of weak passwords to the user community. As noted by TechCrunch: If you’re on Twitter, that means you registered an account with a password that isn’t terribly easy to guess. As you may know, Twitter prevents people from doing just that by indicating that certain passwords such as ‘password’ (cough cough) and ‘123456’ are too obvious to be picked. It just so happens that Twitter has hard-coded all banned passwords on the sign-up page. All you need to do to retrieve the full list of unwelcome passwords is take a look at the source code of that page. Do a simple search for ‘twttr.BANNED_PASSWORDS’ and voila, there they are, all 370 of them. The common attack vector is to perform a dictionary attack on known accounts. A good dictionary is an important factor for success. It is much easier to create a good dictionary if you know for certain many common passwords will not be present. Making the list easy to discover makes it much easier for someone to tune their dictionary. I applaud Twitter for trying to improve passwords and thereby making them tougher to guess, but targeted attacks just got better as well. Because here’s a list of 370 passwords I don’t have to test. Share:

Share:
Read Post

My Personal Security Guiding Principles

Fall of 2009 marks the 20th anniversary of the start of my professional security career. That was the first day someone stuck a yellow shirt on my back and sent me into a crowd of drunk college football fans at the University of Colorado (later famous for its student riots). I’m pretty sure someone screwed up, since it was my first day on the job and I was assigned a rover position – which normally goes to someone who knows what the f&%$ they are doing, not some 18 year old, 135-lb kid right out of high school. And yes, I was breaking up fights on my first day (the stadium wasn’t dry until a few years later). If you asked me then, I never would have guessed I’d spend the next couple decades working through the security ranks, eventually letting my teenage geek/hacker side take over. Over that time I’ve come to rely on the following guiding principles in everything from designing my personal security to giving advice to clients: Don’t expect human behavior to change. Ever. You cannot survive with defense alone. Not all threats are equal, and all checklists are wrong. You cannot eliminate all vulnerabilities. You will be breached. There’s a positive side to each of these negative principles: Design security controls that account for human behavior. Study cognitive science and practical psychology to support your decisions. This is also critical for gaining support for security initiatives, not just design of individual controls. Engage in intelligence and counter-threat operations to the best of your ability. Once an attack has started, your first line of security has already failed. Use checklists to remember the simple stuff, but any real security must be designed using a risk-based approach. As a corollary, you can’t implement risk-based security if you don’t really understand the risks; and most people don’t understand the risks. Be the expert. Adopt anti-exploitation wherever possible. Vulnerability-driven security is always behind the threat. React faster and better. Incident response is more important than any other single security control. With one final piece of advice – keep it simple and pragmatic. And after 20 years, that’s all I’ve got… Share:

Share:
Read Post

Prison Computer ‘Hacker’ Sentenced

I just noticed this story in my feed reader from before Christmas. I don’t know why I found the Computerworld story on the Massachusetts inmate ‘hacker’ so funny, but I do. Perhaps it is because I envision the prosecutor struggling to come up with a punishable crime. In fact I am not totally sure what law Janosko violated. An additional 18 month sentence for ‘abusing’ a computer provided by the correctional facility … I was unaware such a law existed. Does the state now have to report the breach? In 2006, Janosko managed to circumvent computer controls and use the machine to send e-mail and cull data on more than 1,100 Plymouth County prison employees. He gained access to sensitive information such as their dates of birth, Social Security Numbers, telephone numbers, home addresses and employment records. That’s pretty good as terminals, especially those without USB or other forms of external storage, can require a lot of manual work to hack. I bet the prosecutors had to think long and hard on how to charge Janosko. I don’t exactly know what ‘abusing’ a computer means, unless of course you do something like the scene from Office Space when they exact some revenge on a printer. He pleaded guilty to “one count of damaging a protected computer”, but I am not sure how they quantified damages here as it seems improbable a dumb terminal or the associated server could be damaged by bypassing the application interface. Worst case you reboot the server. Maybe this is some form of “unintended use”, or the computer equivalent to ripping off mattress tags. If I was in his shoes, I would have claimed it was ‘research’! Share:

Share:
Read Post

2009 Wrap: Changes in Perspective

It’s easy to say that every year’s been a big year, but in our case we’ve got the goods to back it up. Aside from doubling the size of the Securosis team, I added a new member to my family and managed to still keep things running. With all our writing and speaking we managed to hit every corner of the industry. We created a new model for patch management, started our Pragmatic series of presentations, popped off a few major whitepapers on application and data security, launched a new design for the site, played a big role in pushing out the 2.0 version of the Cloud Security Alliance Guidance, and… well, a lot of stuff. And I won’t mention certain words I used at the RSA Conference (where we started our annual Disaster Recovery Breakfast), or certain wardrobe failures at Defcon. On the personal front, aside from starting my journey as a father, I met Jimmy Buffett, finally recovered enough from my shoulder surgery to start martial arts again, knocked off a half-marathon and a bunch of 10K races, spent 5 days in Puerto Vallarta with my wife, and installed solar in our home (just in time for a week of cloudy weather). It’s been a pretty great year. I’ve never been a fan of predictions, so I thought it might instead be nice to collect some lessons learned from the Securosis team, with a peek at what we’re watching for 2010. – Rich Adrian The biggest change for me over the last year has been my transformation from CTO to analyst. I love the breadth of security technologies I get to work with in this role. I see so much more of the industry as a whole and it totally changed my perspective. I have a better appreciation for the challenges end users face, even more than as a CIO, as I see it across multiple companies. This comes at the expense of some enthusiasm, the essence of which is captured in the post Technology vs. Practicality I wrote back in July. Moving forward, the ‘Cloud’, however you choose to define it, is here. Informally looking at software downloads, security product services and a few other security related activities over the last 30 days, I see ‘s3.amazon.com’ or similar in half the URLs I access. This tidal wave has only just begun. With it, I am seeing a renewed awareness of security by IT admins and developers. I am hearing a collective “Hey, wait a minute, if all my stuff is out there…”, and with it comes all the security questions that should have been posed back when data and servers were all on-premise. This upheaval is going to make 2010 a fun year in security. Meier 2009 for me wasn’t a whole lot different than the past couple of years from a consultative role. Although I probably pushed the hardest I ever have this year to build security in as architecture (not as an afterthought) I still, quite often, found myself in a remediation role. Things are changing – slowly. The enterprise (large and mid-size) is very aware of risk, but seems to still only be motivated in areas where it’s directly tied to monetary penalties (i.e., PCI and the government / defense side). I hope next year brings better balance and foresight in this regard. As for 2010 I’m going to agree with Adrian in reference to the ‘Cloud’ and its unquestionable impetus. But it will still be an interesting year of pushing the seams of these services to the limits and finding out where they don’t hold water. Mid to late 2009 showed me some examples of cloud services being pulled back in-house and the use case considerably reengineered. 2010 is going to be a good year for an oft quiet topic: secure network architecture – especially with regards to services utilizing the ‘Cloud’. The design and operation of these hybrid networks is going to become more prevalent as network and transport security are continually hammered on for weaknesses. I’m sure it’s safe to say we’ll see a few cloudbursts along the way. Rich My research moved in a bit of a different direction than I expected this year. Actually, two different directions. Project Quant really changed some of my views on security metrics, and I’m now approaching metrics problems from a different perspective. I’ve come to believe that we need to spend more time on operational security metrics than the management and risk metrics we’ve mostly focused on. Operational metrics are a far more powerful tool to improve our efficiency and effectiveness, and communicate these to non-security professionals. If after decades we’re still struggling with patch management, it seems long past time to focus on the basics and stop chasing whatever is sexy at the moment. I’ve also started paying a lot more attention to the practical implications of cognitive science, psychology, and economics. Understanding why people make the decisions they do, and how these individual decisions play out on a collective scale (economics) are, I believe, the most important factors when designing and implementing security. I learned that we shouldn’t assume everyone has the basics down, and that if we understand how and why people make the decisions they do, we can design far more effective security. On the side, I also learned a lot about skepticism and logical fallacies, which has heavily influenced how I conduct my research. Our security is a heck of a lot better when it’s mixed with a little science. In 2010 I plan to focus more on building our industry up. I’d like to become more involved in information-sharing exercises and improving the quality of our metrics, especially those around breaches and fraud. Also, like Hoff and Adam, I’m here if Howard Schmidt and our government call – I’d love to contribute more to our national (and international) cybersecurity efforts if they’re willing to have me. We need to stop complaining and start helping. I’ve been fortunate to have a few opportunities to

Share:
Read Post

Hosting Providers and Log Security

An interesting discussion popped up on Slashdot this Saturday afternoon about Preventing My Hosting Provider From Rooting My Server. ‘hacker’ is claiming that when he accuses his hosting provider of service interruption, they assume root access on his machines without permission. “I have a heavily-hit public server (web, mail, cvs/svn/git, dns, etc.) that runs a few dozen OSS project websites, as well as my own personal sites (gallery, blog, etc.). From time to time, the server has ‘unexpected’ outages, which I’ve determined to be the result of hardware, network and other issues on behalf of the provider. I run a lot of monitoring and logging on the server-side, so I see and graph every single bit and byte in and out of the server and applications, so I know it’s not the OS itself. When I file ‘WTF?’-style support tickets to the provider through their web-based ticketing system, I often get the response of: ‘Please provide us with the root password to your server so we can analyze your logs for the cause of the outage.’ Moments ago, there were three simultaneous outages while I was logged into the server working on some projects. Server-side, everything was fine. They asked me for the root password, which I flatly denied (as I always do), and then they rooted the server anyway, bringing it down and poking around through my logs. This is at least the third time they’ve done this without my approval or consent. Is it possible to create a minimal Linux boot that will allow me to reboot the server remotely, come back up with basic networking and ssh, and then from there, allow me to log in and mount the other application and data partitions under dm-crypt/loop-aes and friends?” Ignoring for a moment the basic problem of requesting assistance while not wishing to provide access, how do you protect the servers from remote hosting administrators? If someone else has physical access to your machine, even if you machine is virtual, a skilled attacker will gain access to your data regardless. It’s not clear if the physical machine is owned by ‘hacker’ or if it is just leased server capacity, but it seems to me that if you want to keep remote administrators of average skill from rooting your server and then rummaging around in your files, disk encryption would be an effective choice. You have the issue of needing to supply credentials remotely upon reboot, but this would be effective in protecting log data. If you need better security, place the server under your physical control, or all bets are off. Share:

Share:
Read Post

Friday Summary- December 18, 2009 – Hiatus Alert!

This is going to be a pretty short summary. If you noticed, we were were a little light on content this week, due to out-of-town travel for client engagements and in-town client meetings. On a personal note, early this week I had a front tire blow out on my car, throwing me airborne and backwards across four lanes of traffic during the afternoon commute. A driver who witnessed the spectacle said it looked like pole vaulting with cars, and could not figure out how I landed on the wheels, backwards or not. Somehow I did not hit anything and walked away unscathed, but truth be told, I am a little shaken up by the experience. Thank you to those of you who sent well wishes, but everything is fine here. On a more positive note we are gearing up for several exciting events in the new year. New business offerings, a bunch of new stuff on Quant for databases, and a few other surprises as well. But all of this is a lot of work, and it is all going on while we are attending to family matters, so we have decided that this is the last Friday summary of the year. We will have more posts during the holidays, but the frequency will be down until the new year. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences TechTarget video with Adrian talking about email security in the cloud. Rich was quoted in Business Week regarding The Coming Cloud Catastrophe. SearchSecurity podcast with Adrian on database security strategy. Favorite Securosis Posts Akamai Implements WAF Other Securosis Posts MacBook Holiday Sales Report Project Quant for Databases: Project Quant: Database Security Planning, Part 2 (part 4 overall) Project Quant: Database Security Planning (part 3 overall) Favorite Outside Posts Adrian: A classic from Amrit Williams! David: Sockstress Vulnerabilities Patched – Nobody really talking about this which is a shame because it probably deserves much more attention. Watch it resurface in 2010. Top News and Posts Honestly, most of us did not even open our feed readers this week. But one post was making the rounds: Insurgents Hack Drones. Blog Comment of the Week This week’s best comment comes from our own Jeremiah Grossman in response to Adrian’s post on Akamai Implements WAF: Adrian, good post, some bits to consider… One major reason I found this announcement very important is many large website operators who utilize massive bandwidth simply cannot deploy WAFs for performance/manageability reasons. This is why WAFs are rarely found guarding major traffic points. Akamai is known specifically for their performance capabilities so may be able to scale up WAFs where current industry has not. Secondly, WAF rules will always leave some vulnerability gaps, hopefully lesser so in the future, but complete coverage isn’t necessarily a must. The vast majority of vulnerabilities (by raw numbers) are syntax in nature (ie SQLi, XSS, etc.) By mitigating these (at least temporarily) organizations may prioritize the business logic flaws for code fixes–gaps in the WAF. These approach helps getting down to zero remotely exploitable bugs MUCH easier. We’ve experienced as much in our customer-base. “Rule sets are really hard to get right, and must be updated with the same frequency as your web site content. As you add new pages or functions, you are adding and updating rules.” This implies the WAF is deployed in white list mode, which to my understanding is not how Akamai is going to go. ModSecurity Core Rules are black list style, so would not require updates when content is changed. To be fair the rules would have to be changed as the attacks evolve, which may or may be as fast as website/content code changes. Share:

Share:
Read Post
dinosaur-sidebar

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.