Securosis

Menu

Research

Incite 9/10/2014: Smile and Breathe

Mike Rothman September 10, 2014 No Comments

Last week I mentioned how excited I was for the NFL season to be starting. I took the Boy to the Falcons’ home opener and it was awesome. It was a great game, and coming away with a victory in overtime was icing on the cake. As predicted, my voice was a bit rough on Monday from screaming all day Sunday, but it was worth it. I don’t think my son will ever forget that game, and neither will I. Of course, I was expecting Monday to be all about the big victories. Who would have expected Buffalo to beat the Bears at home? Not me – I picked Chicago in my knockout pool, and was promptly knocked out. I’m like Glass Joe I get knocked out so early and often. At least that game happened during the Falcons game, so I wasn’t bothered to be setting $20 on fire. Again. And the Dolphins beating the Pats? Another surprise. But the Monday news cycle was hijacked and dominated by the Ray Rice video. I will not link to it because it’s disgusting. The Ravens cut ties with the guy and now he’s suspended by the NFL. All of which is deserved. Can he rehabilitate himself? Maybe. Can he and his (now) wife work it out? Maybe. Was this an isolated incident, totally shocking and surprising to the people who claim to know him? No one knows that. All we know is that at that moment in time, Ray Rice was a wife-beater. And he’ll suffer the consequences of that action for the rest of his days. But let’s take a more constructive view of the situation. How did he get so angry as to strike the person he claims to love the most? What could he have done differently to avoid finding himself in that situation or role? I don’t have any experience with domestic violence. I don’t let the Boy hit his sisters, no matter what they do. But I do know a thing or two about anger. Anger (and my inability to manage it) was my catalyst to start moving down the mindfulness path, as I described in my RSA talk with JJ (link below). I am not going to preach the benefits of a daily hour of meditation. I won’t push anything except a little tactic I have learned, to both help me be aware of my increasing frustration, and to stop the process before it turns to anger and then rage. When I feel my fight or flight instincts kicking in, I smile and then take a deep breath. That brings my awareness out of the current stressful situation and lets me take a step back before I do something stupid. It allows me to sit with my frustration and not allow it to become anger. If it sounds easy, that’s because it is. It takes discipline to not take the bait, but it’s easy to do. Of course this is not the right approach if you are being chased by a lion or an angry mob. At that point your fight or flight instincts are right on the money. But as long as your life is in no danger, a smile and then a deep breath work. At least they do for me. You will get strange looks when you break into a smile during a tense situation. Folks may think you are crazy, and may get more fired up that you aren’t taking them seriously. I don’t worry about what other people think – I figure they prefer a smile to a felonious assault. We all need tactics to handle the stress in our lives. Figure out what works for you, and make it a point to practice. The unfortunate truth is that if you do security you will have plenty of opportunities for practice. –Mike Photo credit: “[077/365] Remember to Smile” originally uploaded by Leland Francisco The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling May 5 – There Is No SecDevOps April 28 – The Verizon DBIR April 14 – Three for Five Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. The Security Pro’s Guide to Cloud File Storage and Collaboration Additional Security Features Core Security Features Overview and Baseline Security Introduction Trends in Data Centric Security Deployment Models Tools Introduction Use Cases Understanding Role-based Access Control Advanced Concepts Introduction NoSQL Security 2.0 Understanding NoSQL Platforms Introduction Newly Published Papers The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Incite 4 U Pay Apple: With Apple’s announcement today of Apple Pay, they have now released some details of how their payment architecture will work. Yes, it’s a

Share:
Read Post

Secure Agile Development: Agile and Agile Trends

Adrian Lane September 10, 2014 No Comments

If you are a developer reading this series, you probably have a feel for what Agile development means. For those of you who don’t live it every day, or have read the exceedingly poor Wikipedia page on Agile software development, you are probably wondering what this is all about. In the simplest terms, Agile software development is a set of techniques for building the intended software with fewer errors and better predictability. Each technique is intended to address common failures in ‘waterfall’ development: complexity, poor communication, and infrequent code validation. So Agile approaches embrace simplicity of task, fast turnaround for smaller pieces of working code, and a preference for human interaction over email/document/process oriented interaction. Simpler tasks make it harder for developers to misunderstand what the code is meant to do. Faster iteration produces working code more often, with three distinct benefits: early confirmation that you are building the correct solution, quicker detection of breakage, and more accurate project completion estimates. Face-to-face human interaction helps clarify what everyone on the team is building, and greatly reduces communication errors – which are far too common with ambiguous documentation and code specifications. Smaller, simpler, and faster. The most popular flavor of Agile today, by a large margin, is Agile with Scrum. Each characteristic of this approach has been selected to support agility. For example short development ‘sprints’, typically 1-4 weeks, are used rather than the 18-month cycles common to traditional waterfall development. Agile with Scrum relies on daily ‘scrum’ meetings, where all the developers meet face-to-face to discuss what they will be working on that day. Developers receive their tasks on 3×5 cards, which quite effectively limits task complexity. Each sprint focuses on iterative improvements rather than complete feature delivery. This ensures that only functional code modules are checked in – unlike waterfall where every feature is typically crammed in on deadline. If you need more information, Ken Schwaber’s book Agile Project Management with Scrum is the best reference we have found, so pick up a copy if you want detailed information. So why do security professionals care? Because development has shifted focus to smaller, simpler, and faster – effectively excluding slow, indeterminate, and complex security tasks. Over the past 15 years development processes have evolved from waterfall, to rapid development, to extreme programing, to Agile, to Agile with Scrum, to the current darling: DevOps. Each evolutionary step was taken to build better software by improving the process of building software. And each step embraced changes in tools, languages, and systems to encourage Agile processes while discouraging slower and cumbersome processes. The fast flux of development evolution deprecated everything that did not mesh well with the new Agile model – including security. Agile got a bad rap with security because the aspects that promoted better software development (in most ways) broke conventional approaches to building security into code. There are several areas of conflict. Tests that do not fit the Agile process: The classic example is development teams moving to a 2-week Agile ‘sprint’, when security relied on 2 months of automated fuzz testing. Security data that does not integrate with development systems: The classic example is external penetration testers who identify thousands of instances of hundreds of vulnerabilities, then dump unexplained findings onto development teams, who have no idea what to do with the results. Security tools that do not integrate with development realities: The classic illustration is testing tools which required 100% of code, with all supporting libraries, to be fully built before tests can be conducted. This prerequisite breaks small iterative code changes, delivered weekly or daily. Insufficient knowledge: Just a few years ago most developers did not understand XSS or CSRF, and when they did, it was unclear how these issues should be addressed across the code base. Understanding threats and remediation were not common skills. Getting security into the work queue: The move from waterfall to Agile meant the removal of specific security testing phases, or ‘gates’ in the waterfall process. For security features or fixes to be integrated, they must now be documented as tasks, and then prioritized over other features – otherwise security gets ‘starved’ off the development queue. Policies: A big book of security policies, vulnerabilities, and requirements is extremely un-Agile. One of waterfall development’s most serious issues is large complex specifications that confuse developers. Agile development is an effort to protect developers from such confusing and unwieldy presentation of essential information. During this amazing period of advancement in software development, we have seen an equally amazing evolution among hackers and attacks against applications of all sorts. Security has largely remained static, but there are plenty of ways to integrate security into software development, provided you are willing to make the necessary adjustments. Our next post will help you do so. Share:

Share:
Read Post
dinosaur-sidebar

Research

view all

Sign Up for Our Newsletter

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.