Slashdot Mirror
IEEE Guides Software Architects Toward Secure Design
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.
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.
take your head outa your ass for a few minutes, not everything is republican and democrat here. This has NOTHING To do with politics. we are all dumber for having listened to you, I award you no points, and may god have mercy on your soul
have you seen my sig? there are many others like it but none that are the same
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 for big business to follow when architecting new software designs would somehow annoy them because somehow people would suddenly be required to use such standards to develop software like SSL/LTSP/SSH/etc?
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 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.
I'm not saying that ideas like object orientation, design patterns, design principles, etc., are unimportant, nor am I saying that an overall application structure like Model-View-Controller, or Extract-Transform-Load, is wrong. But the continued efforts wasted trying to make Big Design Up Front work leads to unimaginably expensive wasteful processes that only work for a very limited, very rigid set of products, and of those most fail anyway. Worse is when non-developers fail to realize that the code itself is the language of design. Back to the construction analogy, people think that an engineer produces a blueprint, then 100 people grab hammers and shovels and build the building. Hire 200 people. They don't all have to be skilled laborers, either, some are just guys with shovels and hammers. Want it to go up faster? But in software development, anything automatable has already been automated. When a software developer needs to do "construction", he or she types "make". Want it to go faster? Buy a bigger build server.
The engineering the IEEE is trying to achieve is accomplished by test-first development, continual automated testing, and peer code reviews. It is not achieved by producing thousands of documents, months of procedures, and boards of review.
John
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.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Too bad the document just rehashes the same platitudes you hear everywhere else. Nothing to see here . Move along
Shameless plug:
http://www.osnews.com/story/22...
Biggest lesson I learned... Do not claim the compiler is a perfect machine :P
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 hours and then they spend months doing confirmatory biased research to flesh out the justifications for their original idea. That's the waste. As the plover said, all that knowledge about design patterns, etc. is still applicable. Just don't do it in a big up-front fashion.
Helping with organizational effectiveness is our job.
Thanks for the comments. I really appreciate your final comment! I'm a big proponent of good engineering practices over bureaucratic engineering processes!
Helping with organizational effectiveness is our job.
You can't have PHP or JVM, and secur(e|ity) in the same sentence. There will be no real security short of people quibbling and lying through their teeth, to themselves and others, until the proliferation of the JVM and PHP has subsided. Those two have caused more security vulnerabilities than religion has caused deaths and useless wars. If you're not against the JVM, then you're anti security. Plain and simple.
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 down the stack, backup threads, and bring the whole mess down. Thanks Mr. Architect!
Yup!!! I think everyone building software should spend time supporting their software! This is part of what the software craftsmanship movement is about.
Helping with organizational effectiveness is our job.
Clinton is a DINO so the Republicans are responsible for the horrible things he did.
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
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
TOC in the wrong order, and a paper size that isn't available in 95% of the world. How annoying.
Beyond that, not too inspired. But then, if this really is news for a great many programmers Out There, then perhaps the profession is just uninspired--despite what it likes to believe.
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.
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.
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".
Where are we going and why are we in a handbasket?
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 a moment when all the applications were fully functional and there was never a formal switch-over. We re-wrote everything in-place.
Of course, I'm not saying that there was no research, that there was no good design thinking, or that we never thought about the future. But there was certainly no architect and there was not technical lead who had the final authority on the overall design or any particular detail.
I've seen this approach work with $20M projects and with $200K projects. I've seen it work and result in systems with zero defect rates extended over years. I've seen it work on systems with thousands of lines of code and systems with millions of lines of code. It's possible, it's just that most people have been so brainwashed by the construction analogy and "scientific management" thinking that it's hard to imagine that it's possible.
Helping with organizational effectiveness is our job.
Great article! Thanks!
Helping with organizational effectiveness is our job.
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.
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, 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?
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, have tested it ahead of time). There have been high-profile outages of the main web site due to the way the CMS was "architected". She gets paid a ton of money to do something that should be done in software.
Maybe you worked on the trading platform or other systems, but if the internal systems used for content management are any indication, I'd say you did a terrible job and maybe could have benefited from an architect.
My biggest issue with people who don't like architects is this: they usually have never really had to deal with the consequences of their actions and just assume they did a great job. Of course, most architects have the same problem. Large corporations are excellent at breeding this mentality (I know, because I've had to clean up shit from people who reported to the CIO and completely f'd up agile). You'll note that the problem I'm really highlighting here is that in big corporations, software is usually shit and people are applauded for it anyway, regardless of whether they used agile, waterfall, or nothing at all. Everyone thinks they did a great job because they got paid and promoted and report to important people. How could they be doing anything wrong??? :P
Number 5 is the most important. It is about defending against bad input. When an object (some collection of functions and a mutable state) has a method invoked, the preconditions must be met, including message validation and current state. A lot of code has no well defined interfaces (global states). Some code has state isolated behind functions, but no documented (let alone enforced) preconditions. The recommendation implies a common practice in strongly typed languages: stop using raw ints and strings. Consume input to construct types whose existence proves that they passed validation (ex: a type "@NotNull PositiveEvenInteger" as an argument to a function, etc). DependentTypes (types that depend on values) and DesignByContract are related concepts. With strong enough preconditions, illegal calling sequences can be rejected by the compiler and runtime as well. If secure code is ever going to start being produced on a large scale, people have to get serious about using languages that can express and enforce logical consistency.
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 of a big agile project that fell over its lack of architecture. Coplien Lean Architecture: for Agile Software Development is nearer the mark. He is, after all, an expert programmer as well as a software architect.
"In the quest for truth we must train ourselves to view our favourite ideas just as critically as those we oppose"
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.
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.
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 can still make poor decisions in any framework, which does not necessarily invalidate that framework. The good thing about an Agile approach is that as long as the team is there, the software can still be easily changed.
And if she hasn't already, your wife has the responsibility to file a bug report or at least report her concerns to the stakeholder - the team may not even know of this need for bulk updating, or the financial impact of the one-at-a-time process. It sounds like it's fairly easy to quantify the cost of the inefficiency, which should help prioritize it accordingly.
John
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 that as software security is very hard, a specialized form of the Dunning-Kruger effect applies. The things I have seen people do that though they understood software security are staggering. Unless you have achieved a holistic view of the problem-space, do not even try to design any security critical software.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
indeed there is a lot of BS in agile and you are a perfect proof of that.
Yes agile myth is strong - you may always claim that team was not agile enough and problem is solved.
I saw Southerland presentation at google conf few times now and I must say that I understand how he can claim improved productivity by few hundred percent - this does not work for most of the others.
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 card permissions don't have separate settings for "read and write the app's own folder and folders explicitly chosen by the user" and "read and write the whole damn thing". Internet permissions don't have separate settings for "communicate only with a specific set of hostnames" and "communicate with everything". Phone state permissions don't have separate settings for "read whether the phone is ringing as a cue to pause the game or video and save the user's work immediately" and "read the identity of the cellular subscriber whose SIM is in this device".
The other problem is that unlike (say) Bitfrost in OLPC Sugar, Android's model isn't designed for users to be able to turn permissions on and off. A user must either grant all privileges that an application requests or not install the application at all. For example, a keyboard app might be able to read the user's location and contacts, ostensibly for adding nearby landmarks and friends' names to the autocorrect. But a privacy-conscious user has no technical means of preventing the application from misusing those permissions. Android 4.3 experimented with "App Ops", an app on Google Play Store to disable individual permissions of individual applications, but Google did away with that in Android 4.4 because it caused too many applications to crash on an uncaught SecurityException.
Those users who are "too sophisticated" may need to write their own software
Until the device blocks sophisticated users from running their own software. This is where the walled garden concept comes in.
Or it could be correctly interpreted as "use digital signatures to verify senders and that the message has not been tampered with."
I understand how you might see a non sequitur, so let me connect the dots. Verifying a sender is only authentication. According to the article, authentication should always be followed by authorization, a decision as to whether or not the system should trust software from a particular sender. A platform owner could play up its strong authentication and gloss over the inflexible authorization policy that follows it. And "inflexible authorization policy" is another word for a walled garden.
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 no longer the architect. We didn't have one. That said, there was a big team of us and we had lots of ongoing discussion about architecture - as we were building out the new systems. No doubt I influenced those discussions somewhat, but I certainly was no longer the authority.
Helping with organizational effectiveness is our job.
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.
Helping with organizational effectiveness is our job.
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.
Helping with organizational effectiveness is our job.
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, can understand big-picture and long-term concerns with the goals and evolution of the software, know and use many appropriate tried and true patterns, and pragmatically marry that with project realities.
Where are we going and why are we in a handbasket?
The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion,
Actually, you could argue for the UI development to use rapid prototyping cycle as well, if the users are actually involved in the process, which would be as nice as having passed automated, system and acceptance testing on a product.