Securosis

Research

Mortality, Integrity, and Risk Management

I despise the very concept of mortality. That everything we were, are, and can be comes to a crashing close at some arbitrary deadline. I’ve never been one to accept someone telling me to do something just because “that’s the way it is”, and I feel pretty much the same way about death. Having seen far more than my fair share of it, I consider it nothing but random and capricious. For those that follow Twitter, yesterday afternoon mortality bitch slapped me upside the head. I found out that my cholesterol is two points shy of the thin black line that defines “high”. Being thirty seven, a lifetime athlete, and relatively healthy eater since my early twenties, my number shouldn’t even be on the same continent as “high”, never mind the same zip code. I clearly have my parent’s genes to blame, and since my father passed away many years ago of something other than heart disease, I get to have a long conversation with mother this weekend on her poor gene selection. I might bring up the whole short thing while I’m at it (seriously, all I asked for was 5’9”). I tend to look at situations like this as risk management problems. With potential mitigating actions, all of which come at a cost, and a potential negative consequence (well, negative for me), it slots nicely into a risk-based approach. It also highlights what is the single most important factor in any risk analysis- integrity. If you deceive yourself (or others) you can never make an effective risk decision. Let’s map it out: Asset Valuation – Really fracking high for me personally, $2M to the insurance company (time limited to 20 years), and somewhere between zero and whatever for the rest of the world (and, I suspect, a few negative values circulating out there). Risk Tolerance – Low. Oh sure, I’d like to say “none”, but the reality is if my risk tolerance was really 0, I’d mentally implode in a clash of irreconcilable risk factors as fear of my house burning around me conflicts with the danger of a meteor smashing open my skull like a ripe pumpkin when I walk outside. Since anything over 100 years old isn’t realistically quantifiable (and 80 is more reasonable), I’ll call 85 the low end of my tolerance, with no complaints if I can double that. Risk/Threat Factors – Genetics, lifestyle, and medication. This one is pretty easy, since there are really only 3 factors that effect the outcome (in this dimension, I’m skipping cancer, accidents, and those freaky brain eating bacteria found in certain lakes). I can only change two of the factors, each of which comes with both a financial cost, and, for lack of a better word, a “pleasure” cost. Risk Analysis – I’m going to build three scenarios: Since some of my cholesterol is good to normal (HDL and triglycerides), and only part of it bad (LDL and total serum), I can deceive myself into thinking I don’t need to do anything today and ignore the possibility of slowly clogging my arteries until a piece of random plaque breaks off and kills me in excruciating pain at an inconvenient moment. Since that’s what everyone else tends to do, we’ll call this option “best practices”. I can meet with my doctor, review the results, and determine which lifestyle changes and/or medication I can start today to reduce my long term risks. I can reduce the intake of certain foods, switch to things like Egg Beaters, and increase my intake of high fiber food and veggies. I’ll pay an additional financial cost for higher quality food, a time cost for the extra workouts, and a “pleasure” cost for fewer chocolate chip cookies. In exchange for those french fries and gooey burritos I’ll be healthier overall and live a higher quality of life until I’m disemboweled by an irate ostrich while on safari in Africa. I can immediately switch to a completely heart-healthy diet and disengage from any activity that increases my risk of premature death (and isn’t all death premature?). I’ll never eat another cookie or french fry, and I’ll move to a monastery in a meteor-free zone to eliminate all stress from my life as I engage in whatever the latest medical journals define as the optimum diet and exercise plan. I will lead a longer, lower quality life until I’m disemboweled by an irate monk who is sick of my self righteous preaching and mid-chant calisthenics. We’ll call this option the “consultant/analyst” recommendations. Risk Decision and Mitigation Plan – Those three scenarios represent the low, middle, and high option. In every case there is a cost- but the cost is either in the short term or the long term. None of the scenarios guarantees success. This is where the integrity comes in- I’ve tried to qualify all the appropriate costs in each scenario, and don’t try and fool myself into thinking I can avoid those costs to steer myself towards the easy decision. It would be easy to look at my various cholesterol levels and current lifestyle, then decide that maybe if I read the numbers from a certain angle nothing bad will happen. Or maybe I can just hang out without making changes until the numbers get worse, and fix things then. On the other end, I could completely deceive myself and decide that a bunch of extreme efforts will fix everything and I can completely control the end result, ignoring the cost and all the other factors out there. But if I’m really honest to myself, I know that despite my low tolerance for an early death, I’m unwilling to pay the costs of extreme actions. Thus I’m going to make immediate changes to my diet that I know I can tolerate in the long term, I’ll meet with my doctor and start getting annual tests, and I’ll slip less on my fitness plan when work gets out of control. I’m putting metrics in place

Share:
Read Post

The Biggest Difference Between Web Applications And Traditional Applications.

Adrian and I have been hard at work on our web application security overview series, and in a discussion we realized we left something off part 3 of the series when we dig into the differences between web applications and traditional applications. In most applications we program the user display/interface. With web applications, we rely on an external viewer (the browser) we can’t completely control, that can be interacting with other applications at the same time. Which is stupid, because it’s the biggest, most obvious difference of them all. Share:

Share:
Read Post

WebAppSec: Part4, The Web Application Lifecycle

Just prior to this post, it dawned on us just how much ground we are covering. We’re looking at business justification, people, process, tools and technology, training, security mindset and more. Writing is an exercise in constraint- often pulling more content out than we are putting in. This hit home when we got lost within our own outline this morning. So before jumping into the technology discussion, we need to lay out our roadmap and show you the major pieces of a web application security program that we’ll be digging into. Our goal moving forward is to recommend actionable steps that promote web application security, and are in keeping with your existing development and management framework. While web applications offer different challenges, as we discussed in the last post, additional steps to address these issues aren’t radical deviations from what you likely do today. With a loose mapping to the Software Development Lifecycle, we are dividing this into three steps across seven coverage areas that look like this: Secure Development Process and Training – This section’s focus is on placing security into the development life-cycle. We discuss general enhancements, for lack of a better word, to the people who work on delivering web applications, and the processes used to guide their activity. Security awareness training through education, and supportive process modifications, as a precursor to making security a functional requirement of the application. We discuss tools that automate portions of the effort; static analysis tools that aid engineering in identifying vulnerable code, and dynamic analysis tools for detecting anomalous application behavior. Secure SDLC- Introducing secure development practices and software assurance to the web application programming process. Static Analysis- Tools that scan the source code of an application to look for security errors. Often called “white box” tools. Dynamic Analysis- Tools that interact with a running application and attempt to ‘break’ it, but don’t analyze the source code directly. Often called “black box” tools. Secure Deployment At the stage where an application is code-complete, or is ready for more rigorous testing and validation, is the time to confirm that it does not suffer serious known security flaws, and is configured in such a way that it is not subject to any known compromises. This is where we start introducing vulnerability assessments and penetration testing tools- along with their respective approaches to configuration analysis, threat discovery, patch levels, and operational consistency checking. Vulnerability Assessment- Remote scanning of a web application both with and without credentialed access to find application vulnerabilities. Web application vulnerability assessments focus on the application itself, while standard vulnerability assessments focus on the host platform. May be a product, service, or both. Penetration Testing- Penetration testing is the process of actually breaking into an application to determine the full scope of security vulnerabilities and the risks they pose. While vulnerability assessments find security flaws, penetration tests explore those holes to measure impact and categorize/prioritize. May be a product, service, or both. Secure Operation In this section we move from preventative tools & processes to those that provide detection capabilities and can react to live events. The primary focus will be on web application firewalls’ ability to screen the application from unwanted uses, and monitoring tools that scan requests for inappropriate activity against the application or associated components. Recent developments in detection tools promote enforcement of policies, react intelligently to events, and couple several services into a cooperative hybrid model. Web Application Firewalls- Network tools that monitor web application traffic and alert on, or attempt to block, known attacks. Application and Database Activity Monitoring- Tools that monitor application and database activity (via a variety of techniques) for auditing and to generate security alerts based on policy violations. Web application security is a field undergoing rapid advancement- almost as fast as the bad guys come up with new attacks. While we often spend time on this blog talking about leading edge technologies and the future of the market, we want to keep this series grounded in what’s practical and available today. For the rest of the series we’re going to break down each of those areas and drill into an overview of how they fit into an overall program, as well as their respective advantages and disadvantages. Keep in mind that we could probably write a book, or two, on each of those tools, technologies, and processes, so for these posts we’ll just focus on the highlights. Share:

Share:
Read Post

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.