IEEE Guides Software Architects Toward Secure Design 51
msm1267 writes: The IEEE's Center for Secure Design debuted its first report this week, a guidance for software architects called "Avoiding the Top 10 Software Security Design Flaws." Developing guidance for architects rather than developers was a conscious effort the group made in order to steer the conversation around software security away from exclusively talking about finding bugs toward design-level failures that lead to exploitable security vulnerabilities. The document spells out the 10 common design flaws in a straightforward manner, each with a lengthy explainer of inherent weaknesses in each area and how software designers and architects should take these potential pitfalls into consideration.
Re: (Score:2)
There's a ton (or a megabyte) wrong with the hardware/software construction analogy, but organizations like the IEEE keep pushing on it because that's the way people look at "engineering".
The problem is the analogy makes everyone who doesn't understand software think there has to be some "big design up front" before you write software. Of course, when the end product is as infinitely malleable as software, that's simply not true. The human interface needs a design in order to mesh with the humans in an el
Re: (Score:1)
Thanks for the comments. I really appreciate your final comment! I'm a big proponent of good engineering practices over bureaucratic engineering processes!
API consistency; negative tests (Score:4, Insightful)
Of course, when the end product is as infinitely malleable as software
Software isn't "infinitely malleable" when it exposes interfaces to anything else. This could be APIs to other software or user interfaces. You have to build on the old interface compatibly, and when you do make a clean break, you need to keep supporting the old interface until others have had a reasonable time to migrate.
The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion, but the code? No. The only purpose of code design is to make the code readable and maintainable, and those are attributes you achieve through test driven development and continual refactoring.
APIs need at least as much consistency as UIs. In fact, I'd argue that APIs need even more consistency because human users are slightly better at adapting to a UI through reflection, that is, figuring out a UI by inspection.
The engineering the IEEE is trying to achieve is accomplished by test-first development
Then take this guide as something to consider when determining when you have enough negative tests [stackoverflow.com], or tests that are expected to succeed by failing.
continual automated testing
If you're using a CAPTCHA as part of a process to authenticate a user, how do you perform automated testing on that?
Re: (Score:2)
Software is malleable in that whatever is on the inside can be safely changed through refactoring to meet your new design goals. And yes, you have to adhere to strong design principles: the open/close principle helps ensure that you can safely migrate to a new API while still supporting your old clients; the interface segregation principle helps ensure that your clients are always getting the right service without confusion; and you have to commit to serious code coverage metrics for your automated tests.
Re: (Score:2)
I don't disagree with your overall premise: bureaucratic 'big design up front' methods don't work except for an exceedingly small subset of problems in the real world.
However, you largely ignore a key point that I think the IEEE is (belatedly) trying to address: our focus from a design perspective to this point has been first meeting the functional design criteria, and lastly security (if you have time to deal with that at all - which in my experience ends up being the first thing that gets cut when time
Re:Fire the Architects (Score:5, Informative)
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
Your article written on the flaws in the software architect analogy is a good read, but the role of software architect I am used to seems to be far different than the one you are referring to. When I think of a software or systems architect, I am not thinking of someone who is writing or usually even designing software. They are more often determining how different software systems and business processes are interacting with each other. In most situations, each of these software systems is a black box to the architect. The only software code the architect is usually responsible for is any custom middle-ware products needed to help each system interface with each other.
In this context, many of the critiques you mentioned in your 2003 article are not as valid. Systems architectures are not easily duplicated for different companies, just like a building cannot be easily duplicated. And when working with software products that are often black boxes, the software architect will likely be just as constrained as a construction architect (although usually not by as many regulations and codes).
Obviously there are strong differences between the fields, but there are strong differences between mechanical / electrical / chemical engineers as well. And just as the word engineer has evolved from someone who builds medieval machines of war, I personally see no problem with the word architect evolving from just someone who designs and supervises the construction of buildings.
Re: (Score:2)
True enough: the article on Kuro5hin is very old... I've often thought of writing an update to take in to account some of the things you mention. (Actually, it's hard to believe I wrote that 11 years ago!)
Still, I feel that most software architects really inflate the importance (and time) of their jobs. It's true that there is some amount of legitimate research to be done in exploring the broad outlines of your solution. However, most of the time those solutions are dreamed up by the architect in a few h
Re: (Score:2)
My biggest problem with architects - they don't get to enjoy the fruits of their labors by doing production support :)
If every architect was required to be 24/7 on call support for the first 6 months after their design was released to production, they'd be a shitload more careful in what kinds of things they dream up. Sure, that black box back end with all that data sure looks pretty, but thanks to that decision to query it 1000 times per API call, means that you're going to blow through timeouts up and do
Re: (Score:2)
Yup!!! I think everyone building software should spend time supporting their software! This is part of what the software craftsmanship movement is about.
Re: (Score:2)
Shameless plug:
http://www.osnews.com/story/22... [osnews.com]
Biggest lesson I learned... Do not claim the compiler is a perfect machine :P
Re: (Score:2)
Great article! Thanks!
Re:Fire the Architects (Score:5, Insightful)
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
It *sounds* like you've never worked on a large project then. Fine, fire the architects, but you're still going to need someone to do their job, no matter if you call them the team lead or something else. There needs to be a *technical* person at the top who says "we're marching that way" and here's some stuff we need to keep in mind and do. Some technical person who can push back to the product owner when it's needed and explain in technical gory details when required. That's not the project manager because they're not technical enough; or that's been true for all the projects I've ever worked on.
... the cheapest time to change software is during the planning stage before it's written.
You need someone to can look ahead at the items coming and notice that there are some common things needed, and that if you spend some time up front to fix (a framework, a subsystem, whatever) that it will be cheaper and faster to do that way than to let small bits of code be written and then refactored a hundred times as the sprints slowly come in.
I'm sorry you don't like the construction analogy, but it's very true that the cheapest time to change a building is when you're still at the blueprint stage before it's built
Sure, most product owners owners don't really know where they want to end up, but some things are well known and when you have that knowledge you should use it as soon as possible, no matter what you want to call the roles or the results. Protocols, APIs, security, data models and databases, etc are all things that should be planned as much as possible, not organically grown and refactored. Who does that planning?
My day job right now is dealing with code that had very little upfront planning, very Agile'ish, and the system is a nightmare at times. I'll admit that the source of the problem may be that the devs before me never came back and refactored and cleaned up, but a little more planning would have made much of that unnecessary. That's what an architect brings to the table: some overall planning and technical sense.
Re: (Score:1)
I was the senior architect reporting to the CIO of Charles Schwab. I was responsible for huge systems at an architectural level. Then, with the permission of the CIO we launched a two year enterprise re-write covering hundreds of applications and dozens of technology platforms from old green-screen cobol systems to modern Java and .NET systems... and we did it with no up-front architecture. Pure Agile, with all the process and engineering practices to do it properly. Huge success because there was never
Re: (Score:2, Interesting)
Ha! My wife works with systems you likely developed, or at least had to have gone through the CIO's office. You clearly have never had to use any of the systems you created. The CMS, in particular, is one of the worst pieces of corporate software I've ever seen. A big part of her job is pushing files _one_at_a_time_ to the production systems because there is no way to do bulk updates. Rolling back is just as painful if a problem is discovered during a rollout (other groups submit the content and, in theory
Re: (Score:1)
Maybe the requirement to upload bulk updates was a lower priority for that development team than getting other features implemented, and it's still on their stack. Or maybe they ran out of budget before getting to implement that feature. Maybe the stakeholder who was assigned to work with that development team failed to understand his or her own user base - the stakeholder's job is to provide the business perspective, and maybe he thought a pretty color scheme was more important than bulk uploads.
People c
Re:Fire the Architects (Score:4, Insightful)
I love your claim that you rewrote Charles Schwab from the ground up with no architectural plan in place yet state that you were the chief architect. Your up-front architecture was the old systems you were replacing. You had laid out before you everything that had to be accomplished, what had to talk with what and how as you went through the process of replacing and retiring systems.
Just because you don't want to recognize that as up-front architecture doesn't mean it wasn't there and you didn't do it.
Of course, taken literally, your statement also admits that the whole thing never actually worked: "there was never a moment when all the applications were fully functional." I'll choose to read that combined with the sentence that follows as you did not do the whole rewrite before switching to the new system. That is more evidence that you were using the existing system as an architectural guide to how the system communicated.
Re: (Score:2)
Oops. Meant to say "there was never a moment when all the applications weren't fully functional.
It's true that the old system(s) were a sort of guide, but it really was a complete replacement/re-architecture. Not only that, but there was no time in the project when we had a document that said "this is the current architecture". We had to do a lot of exploring along the way.
My job title prior to the project was architect but I told the CIO that it was unnecessary and so at the start of the project I was n
Re:Fire the Architects (Score:4, Insightful)
I suspect that most programmers who don't see the need for software architecture work within the confines of already heavily architected frameworks, platforms, and network stacks.
Thus their comments are akin to saying "I don't think we need an architect to help us rearrange the furniture and paint on the walls".
Re: (Score:1)
all software architects ever do is waste and overhead from a lean perspective.
I have worked with software architects who might fit your description but for a big system to succeed someone competent still has to do the architecture. Kruchten for instance notes an example [wordpress.com] of a big agile project that fell over its lack of architecture. Coplien Lean Architecture: for Agile Software Development [wiley.com] is nearer the mark. He is, after all, an expert programmer as well as a software architect.
Re: (Score:2)
Lack of architecture is not the same as lack of an architect. Indeed, no architecture in a system == chaos. But how you get good architecture, unfortunately, is rarely from architects.
Re: (Score:2)
I don't know about you, but I'd say that someone who is creating architecture, is, oh, I don't know, an architect.
Who cares about the title. "Chief codemonkey with a clue" will do just fine.
There seems to be some mythology out there about software architects who don't come from coding.
Sort of like MBA managers.
Never seen one of those. If they're not still coding, they don't love the craft enough to be good architects.
To me, it's just someone who can model a complex system in different cross-cutting aspects,
Re: (Score:1)
Your articles show you've never actually worked in construction. Or if you did, you had no idea what you were doing.
Extreme programming, they've been throwing that bullshit around for decades.
Re: (Score:2)
I did work in construction (and land surveying, and drafting, and other related fields) but only for a short time. So maybe I had no idea what I was doing... but that's actually the point of the article: software folks who want to use the construction analogy to come up with an "architect role" are doing something from a place of profound ignorance and the analogy is deeply flawed.
Re:I love it when the IEEE... (Score:4, Insightful)
Yeah, you mean that damn "Republican" Bill Clinton who was in office in 1996 when ITAR and EAR resulted in the DOJ going after Phil Zimmerman?
In case you hadn't noticed, Clinton was and is a Democrat, and the President is in charge of the Executive branch agencies.
Re: (Score:1)
Well, that's a fair enough argument I guess. Neither Bill nor Hillary are as hardcore along party lines as some. I'd hardly place them with the Republicans, but they are closer to moderate/centrist Republicans than to a lot of the Democratic party. In the same way, lots of Republicans are closer to moderate/centrist Democrats than to the fringe right.
Re: (Score:3, Insightful)
Re: (Score:2)
It took me a while to parse your comment... as the IEEE is an international standards body. Then I realized that you weren't talking about nation states, but half of the party system in the US... and then was lost again figuring out how a standards body pushing a security standard for SAs related to political gerrymandering in the US. Did you mean that the Republican party of the US is intentionally trying to make the Internet less secure, and that an international standards body setting down guidelines f
Re: (Score:3)
You can. But you need to be aware that 99.9% of people doing PHP or Java or the JVM do not have what it takes to make anything that may see real attacks secure. People that can secure things in this particular problem space are exceedingly rare and exceedingly expensive. One problem is that you cannot use most/all libraries for security critical functions, and may well have to augment the JVM via JNI for secure input validation. Most Java folks are not capable of doing that at all.
Mostly common sense but still good reminders (Score:4, Insightful)
Here it is for anyone who didn't bother to RTFA
1. Earn or Give, but Never Assume, Trust
2. Use an Authentication Mechanism that Cannot be Bypassed or Tampered With
3. Authorize after You Authenticate
4. Strictly Separate Data and Control Instructions, and Never Process Control Instructions Received from Untrusted Sources
5. Define an Approach that Ensures all Data are Explicitly Validated
6. Use Cryptography Correctly
7. Identify Sensitive Data and How They Should Be Handled
8. Always Consider the Users
9. Understand How Integrating External Components Changes Your Attack Surface
10. Be Flexible When Considering Future Changes to Objects and Actors
Number 5 (Score:1)
Re: (Score:2)
Sorry, but no. For example, one of the most important threats these days in the banking industry is data leakage. No amount of input data validation is going to help one bit there. These aspects are all critical. Mess up one, and all is lost. That is what makes software security so difficult: You have to master the whole problem space before you can produce good solutions. Incidentally, there are rules "11: Always consider the business case" and "12: Do a conclusive risk and exposure-analysis and rate and d
Re: (Score:1)
An excuse for walled gardens and OnLive (Score:3)
Video game publishers might take this as an excuse to shift to OnLive-style remote video gaming, where the game runs entirely on the server, and the client just sends keypresses and mouse movements and receives video and audio.
I'm not sure how binary code and assets for a proprietary computer program could be watermarked without needing to separately digitally sign each copy.
For small web sites that don't store financial or health information, I don't see how this can be made affordable. Two-factor typically incurs a cost to ship the client device to clients. Even if you as a developer can assume that the end user already has a mobile phone and pays for service, there's still a cost for you to send text messages and a cost for your users to receive them, especially in the United States market where not all plans include unlimited incoming texts.
How is disclosure of such a URL any different from disclosure of a password? One could achieve the same objective by changing the URL periodically.
This is W^X. But to what extent is it advisable to take this principle as far as iOS takes it, where an application can never flip a page from writable to executable? This policy blocks applications from implementing any sort of JIT compilation, which can limit the runtime performance of a domain-specific language.
What's the practical alternative to hard-coding a key without needing to separately digitally sign each copy of a program?
If the owner of a machine isn't sophisticated enough to administer it, who is? The owner of a computing platform might use this as an excuse to implement a walled garden.
Re: (Score:2)
"How is disclosure of such a URL any different from disclosure of a password? One could achieve the same objective by changing the URL periodically." I believe the article is saying that you don't just blindly allow the use of URLs without verifying that the caller is within an authenticated session. This has nothing to do with changing passwords.
"Google tried this with Android by listing all of an application's permissions up front at application installation time. The result was that some end users ended
Two problems with Android app permissions (Score:2)
I believe the article is saying that you don't just blindly allow the use of URLs without verifying that the caller is within an authenticated session. This has nothing to do with changing passwords.
A newly installed web application has to create a first authenticated session that lets the founder set his own password (or set his own e-mail address in order to recover his password) and grant himself founder privileges. The URL of this first session is effectively a password (or more properly a substitute for a password), though I'll grant that it should be disabled through other means most of the time.
But if you don't want any app to do anything, why do you have a device capable of running apps?
I see at least two problems.
The first is that Android's permissions are far too coarse-grained. SD
This initiative is futile (Score:2)
While the brochure referenced is nice, anybody that needs it has zero business building anything security-critical. It does take a lot of experience and insights to apply the described things in practice in a way that is reliable, efficient and secure and respects business aspects and the user. Personally, I have more than 20 years of experience with software security and crypto, and looking back, I think I became a competent user, designer and architect only after 10 years on this way. The problem here is
Re: (Score:2)
I'd say security failure is partly due to incentive alignment failure for developers.
Bad security design is a problem that's going to bite, but usually a little later, after version 1 is out the door and everyone's paid.
Not meeting the pretty much arbitrary and insanely optimistic delivery schedule is going to bite developers right now.
Corners will be cut, even if some of the developers know what SHOULD be done.
In general, almost every architectural aspect of software, including security, (well-factoredness
Re: (Score:2)
While that certainly plays a role, it is a minor one. It does stand in the way of solving things, but if you do not have developers that can do secure software engineering competently (and that is the normal case), then giving them too little time and money to do secure software engineering does not matter. The other thing is that people that actually understand software security are much less likely to declare something finished or secure than those with only a superficial understanding of things. Software