Profile cover photo
Profile photo
John Steven
iCTO Cigital, CTO Codiscope ~ Build Security In ~ Software Security Crossover Dubstep
iCTO Cigital, CTO Codiscope ~ Build Security In ~ Software Security Crossover Dubstep

John's posts

Post has attachment
Recording of my webinar with 451 Group's Wendy Nather is up:  We discussed why dynamic testing isn't enough and why software testing as a service must:

* Cover the whole portfolio, not just "high risk apps";
* Take a risk-based approach, right-sizing testing to the app, its quality, and risk;
* Leverage multiple tools;
* Include manual effort on top of tools;
* Focus on gaining coverage.  

Feel free to reach out to me for more information or with questions.

Post has attachment
Today, #Cigital's Kevin Glavin is doing a talk on Django security @ 1:00pm EST today. As a Senior Security Consultant and Developer using Django, Kevin has packed this presentation with a lot of good information and can answer specific questions beyond the material.

Register now at:

Post has attachment
#Cigital  proud to announce the launch of #IEEE's "Center for Secure Design", Directed by our own Jim Delgrosso. Find more information at: 

This effort is committed to building security into software from the start in order to avoid design flaws which persist regardless of how much assessment an application undergoes. 

Post has shared content
#SSO and the broader problems its interactions with AuthN kit show up constantly regardless of whether we analyze architecture, review code, or penetration test. Our Jacob Ewers talks about to what you need to pay attention.
As more organizations develop mobile applications for their employees, the need to leverage existing #SSO technologies by mobile applications has arisen. To learn more about SSO implementations and related security concerns download this new Cigital whitepaper.

Post has attachment which Paco meets the BSides Vegas challenge with absolute style and aplomb #winning 

Post has attachment
"I Am Cigital" - Why our diverse staff love what they do and enjoy working with each other so much.

Post has attachment
My new blog entry on Secure Design, answering, "Why is so hard for many to understand where to put security controls in MVC Architecture?"

Building security in means using development frameworks. Using these frameworks means understanding the design patterns they use and each pattern elements' security responsibilities.

Post has attachment
Check out the 100th episode of Gary McGraw's Silver Bullet Podcast ! In this episode he interviewed me as well as Cigital's other principal consultants. 

Our commentary doesn't paint the brightest picture of AppSec's current state but rather than heading for the hills, I see the episode as a challenge to deal with some of our harder problems--rather than continuing to optimize failed approaches.

Post has attachment

OWASP’s impact and stature are dramatically reduced: it no longer
effectively fulfills its role in the AppSec community. Historically, OWASP
played an important and essential role in the AppSec industry across the
board: that of a clearing house for knowledge, techniques, and tools. To
grow, the industry needs a body to continue performing this essential
function, be it OWASP or that which replaces it. I challenge this group to
meet that need.

Following are some examples of OWASP’s fulfilling that role. Following that
are the modern-day challenges in which OWASP is failing the industry.

[Defining the Space, Vocabulary, and Standardization]

OWASP provided the AppSec community a base vocabulary with which to
communicate, a tractable scope for attention, and a canon of knowledge
covering both attack and defense. For example:

* Top 10 - For all its faults, the OWASP Top 10 defined a minimum canon of
attack types and a focus area for organizations starting AppSec programs.
This ‘scope’ shaped a generation of practitioners and programs and
differentiated AppSec as a pursuit separate from NetSec;

* Cheat Sheets, Training, etc - OWASP’s explanation of underlying causes of
and solutions to vulnerabilities have sometimes been tragically wrong but
improve over time. Even when wrong, these resources act as a touchstone for
practitioners and a basis for real craftsmen to differentiate themselves;

Prior to OWASP, it was challenging to even talk about vulnerabilities
organization-to-organization. There was simply no shared understanding of
vulnerabilities, techniques, and controls by name.


Building upon the above, the OWASP community provided an implicit and
defacto standard for practitioners--in absence of an effective
certification body. That helped consumers of AppSec products and services
find (at least marginally) vetted practitioners. Even though the community
tolerated poor practitioners conference speaking, project contribution, and
leadership provided some indication of or dialog towards quality.

[Community and Collaboration]

Finally, OWASP provided avenues through which skilled practitioners
exchanged ideas openly. The community provided critical (and largely
constructive) feedback and a pool of contributors who engaged without much
encumbrance or friction.

=>[Today's Challenges]<=

I don’t think it’s overstating things to say, “AppSec now faces existential
threats from key challenges yet unmet”. If that’s too much to swallow try,
“AppSec’s growth is directly constrained by these unmet needs”. Here they

1) A Software Security Framework - The AppSec Industry *needs* a
“Software Security Framework”, analogous to the Top-10, that describes an
organizations Application Security Initiative

Organizations not longer just conduct training and penetration tests.
Full-fledged software security initiatives exist well beyond early adopter
organizations. There is no widely adopted standard for describing these
initiatives and their constituent elements. OpenSAMM, an idea I proudly
contributed to, was abortive at best. BSIMM’s detractors don’t like its
‘closed’ (yet open) nature. SafeCode is like the OECD—a club for the
mature. Thing exist but the ideas have not gone through any ‘clearing
house’ such that they’re accepted, applied, and working industry-wide.

Without such a framework, many organizations will be constrained by an
underfunded “army of one” app sec initiative dependent on superficial

2) Vulnerability Management Process - The industry *needs* a way to move
from various disparate vulnerability discovery tools/techniques that piles
up bugs to a well-oiled machine by which risk-appropriate security
vulnerability enters development backlog and exists properly remediated.
Solving this problem will require a) normalized naming, classification, and
ranking schemes for tools and techniques (static, dynamic, automated,
manual, <whathaveyou>), b) tools that provide plumbing from security into
development/QA, and c) tie in to a (preferably agnostic) risk management

ThreadFix is my chosen horse for this race. I’m fully behind it without
caveat. It suffers the same status and criticism as BSIMM. The Twitter
team’s OWASP presentations have shown us even more vulnerability management
scaffolding. I’ve implemented robust systems (when Threadfix was still an
infant) as well; they were solutions that better integrate with Enterprise
risk/requirements tools and agile backlog management tools.

Without such a framework and supporting toolset, we’ll continue to chase
SAST and DAST findings in massive and separate piles, ignoring the bulk and
ignorant of which are caused by the same human err. The AppSec industry
will remain segmented into the 80% that piles up vulns, which will persist
release-after-release, and the 20% focused on “Building Security In” and
improving software. In some corners, we’ll continue to see growth and
adoption of mathematically fallacious risk-ranking schemes that
organizations will use dangerously (“Well, I’m OK because I reduced my
app’s vulnerability by 20%… see? Its score went from 5 to 4!”) groan

3) Focus on the Fix - The industry *needs* better advice as how to “Build
Security In”. What is the right way to prevent XSS? What can we rely on
mobile hardening for? How do we store passwords?

Jim Manico’s near relentless push on the Cheat Sheets is one of the few
bright spots I see in OWASP right now and solving this problem doesn't
require a different direction IMO. Instead, it requires far greater

Proprietary repositories for security fixes exist. A few companies are
popping up to address this problem directly. Other old hands have built new
products or knowledge bases to do the same.


Some key AppSec initiatives have stalled and died without an effective
OWASP. Others have moved to proprietary homes where the competence and
support they need remains. Yet, there’s far greater benefit to ALL of us if
today’s challenges (and obvious others I haven’t mentioned) are tackled by
an open organization that combines the competing perspective of many, both
vendors and otherwise. …an organization like OWASP.

These problems may seem like ‘ocean boiling', but they’re not any more so
than others that we—as an industry—have tackled. They can be broken down
into smaller chunks, fought out into imperfect answers, and carried forward
for the benefit of all.

I’ll be ignoring this list from now on. Frankly, it’s an embarrassment.
But, for those of you who still may be listening and are interested in
tackling these problems—I’m interested. Feel free to reach out—you know where to find me.

Phone: 703.727.4034

Post has attachment
Adam Shostack's new book: #ThreatModeling: Designing for security came out in February. In this blog post (  ), I provide commentary on the book with a critical eye towards what practitioners will see within the book and how they can better leverage its material in their own organization.
Wait while more posts are being loaded