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.
Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.
And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.
Two articles that I wrote about this:
The Software Construction Analogy is Broken
and
Technical Push-Back
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.
Helping with organizational effectiveness is our job.
intentionally does things to piss off the Republicans. They've fought against secure software for years. When they crippled SSL with their 40-bit limit and disallowed the distribution of SSH, they were proven to be the enemies of anyone that cares about the Internet.
Too bad the document just rehashes the same platitudes you hear everywhere else. Nothing to see here . Move along
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.
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.
Joint Chiefs of Staff will never allow anything popular to be "secure". Information is power and they want to control population. So the plebs can never have secure computers. Because that would be equal to a SIGABA machine in every household. HORROR !.
Just look at the TLS standard: So complex they can easily fuck it up.
And you betcha, they have fucked up all major CPUs and UARTs and ethernet chips.
All just THEATER. Grow roses or raise geese. That's what NSA does, too.
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?
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.
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.
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.