[WEB SECURITY] Great article outlining a core issue with many in the security community

James Manico jim at manico.net
Tue Feb 15 01:22:05 EST 2011

*>* our architect (or security champion) should translate these use-cases &
abuse cases into more technical requirements, such as - "the system should
protect from horizontal privilege escalation", or "All attempts to
read/write from the database should be validated against SQL Injection to
avoid data corruption or leakage", etc.

This is not prescriptive enough, IMO.  The following requirement:

> the system should protect from horizontal privilege escalation

..only leaves a developer scratching their heads. I would enhance this to
require something along the lines of:

1)      Use a centralized data contextual access control methodology which
restricts users from modifying or viewing data of users with the same role.

2)      Use a centralized authority and a deny-by-default mechanism so that
new features must be configured before being exposed

3)      Hard-code ACTIVITIES in code instead of ROLES so that policy can be
changed in real-time without requiring code changes and re-deployment

> "All attempts to read/write from the database should be validated against
SQL Injection to avoid data corruption or leakage", etc.

This is not an accurate requirement (and is quite dangerous, actually). I
would require something along the lines of

1)      Use parameterized queries and data binding to prevent SQL injection
(both in code and within stored procedures).

2)      When parameterized queries hurt performance, use escaping of each
individual untrusted variable

> These high level requirements, can then be fulfilled by your developers,
using the tools they have - secure coding best practices.

But this is part of the problem. Requirement from security folks are often
inaccurate or “high level”. We need to get clear and prescriptive. I think
the best bet is collaboration between a security architect and a
developer-centric architect to build prescriptive requirements.

- Jim

> The problem is getting owners and stakeholders to think in terms of
> abuse and misuse cases.  Their requirements are always based on the
> “happy path.” “If the user provides the input we are expecting, this
> is how the application should behave.” They define edits and
> exception paths in terms of business logic, but never in terms of
> technical capabilities. They are concerned that a customer may try
> to withdraw more money from their account than the available
> balance, not that they may try to withdraw more money than the input
> buffer is designed to hold. That last type of requirement is up to
> the developer in many shops.
> Even when developers put the question to non-technical stakeholders,
> it often perplexes them: “If the program receives input that it is
> not designed to handle, how should I have the program handle it?”
> Seems a little circular or oxymoronic, doesn’t it? You’re asking for
> a design specification for something that is not in the design.

That's because it is exactly like asking the stakeholders - should I use a
While or a For loop. That's outside their domain. They should define the
security requirements, and the developer should fulfill them. If the
requirements are well defined, everyone will know what to do.

> I’ve sat in requirements sessions and brought up abuse cases where
> the response from the business is, “What are the chances that
> someone will do that?” The answer, as we on this list know, is that
> the chance is low, but when that one determined, skilled individual
> turns his attention to your application, you still need to be ready
> for him. The chances that a burglar is going to try to walk in your
> front door on any given day is pretty low, too, but we all still
> lock our front doors.

That's why you do a risk assessment / threat model, etc. You should come to
the meeting prepared to answer technical questions about the relevance of
each threat or risk, so that the stakeholders will be able to prioritize the

> We need to get rid of the antagonistic Us vs. Them attitude between
> Security and AppDev, and we need to start by a) stopping accusing
> the other of not knowing s**t about the other’s discipline and b)
> admitting that we don’t know s**t about the other’s discipline. Only
> then will we actually start to listen to and learn from each other.

I totally agree.

> -Michael
> From: websecurity-bounces at lists.webappsec.org [mailto:websecurity-<websecurity->
> bounces at lists.webappsec.org] On Behalf Of Ory Segal
> Sent: Monday, February 14, 2011 2:22 AM
> To: robert at webappsec.org
> Cc: websecurity at lists.webappsec.org;
websecurity-bounces at lists.webappsec.org
> Subject: Re: [WEB SECURITY] Great article outlining a core issue
> with many in the security community
> Hi,
> Developers shouldn't be blamed for not writing secure applications -
> it's usually the fault of product owners and stakeholders that don't
> define (and prioritize) security as a critical requirement for a
> software project.
> You don't expect developers to build a pretty and usable user
> interface, you also don't expect them to define the flow and logic
> of your application. That's why product owners and stakeholders have
> to define product requirements, use cases, users, scenarios, etc.
> Developers develop code, which should adhere to the requirements of
> the project.
> As long as security won't be a 1st class citizen in the world of
> software requirements, I suspect we won't see software that is
> secure by design.
> Having security requirements also means that product owners,
> developers and QA teams can verify that the requirements are met.
> They can measure their success, and understand how to get better.
> Anything less than this is simply a waste of time, i.e. bolting
> security on the project in hindsight.
> What we do need to ask ourselves is - if nobody is prioritizing
> security as a critical software requirement - what are we doing wrong
> -Ory
> -------------------------------------------------------------
> Ory Segal
> Security Products Architect
> AppScan Product Manager
> Rational, Application Security
> IBM Corporation
> Tel: +972-9-962-9836
> Mobile: +972-54-773-9359
> e-mail: segalory at il.ibm.com
> [image removed]
> From:        robert at webappsec.org
> To:        websecurity at lists.webappsec.org
> Date:        14/02/2011 12:36 AM
> Subject:        [WEB SECURITY] Great article outlining a core issue
> with many in        the security community
> Sent by:        websecurity-bounces at lists.webappsec.org
> I saw this posted via twitter and thought it was worth mentioning
> here. While the example specifies owasp, I am not posting this link to
> them in particular. I think that the point applies to MANY folks in
> the security industry.
> Security Vs Developers
> Regards,
> - Robert Auger
> WASC Co Founder/Moderator of The Web Security Mailing List
> http://www.qasec.com/
> http://www.webappsec.org/
> _______________________________________________
> The Web Security Mailing List
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> http://twitter.com/wascupdates
> websecurity at lists.webappsec.org
> This E-Mail has been scanned for viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110215/e0c447db/attachment-0003.html>

More information about the websecurity mailing list