Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
10 Common Software Security Design Flaws
Threaded  |  Newest First  |  Oldest First
anon9106759839
50%
50%
anon9106759839,
 User Rank: Apprentice
8/27/2014 | 6:51:54 PM
Nah
Big names, but little value can come from this conversation.

Application security problems stem from attacks. MITRE CAPEC describes the underlying model for attacks, while PTES, OSSTMMv4, and OWASP guides such as the Testing Guide and ASVS 2.0 standards cover the open methods.

There are also models (CWE) and methods (OWASP Dev Guide, SAFEcode, Microsoft SDL, etc) for building secure software, but this is where security and appdev activities are split.

On Twitter, someone important today said, "a design flaw is a property of the design that allows an attacker to violate one of your security objectives".
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
8/28/2014 | 8:16:02 AM
Re: Nah> "little value can come from this conversation"
@anon9106759839 -- Are you saying that there is no significant relationship between security and appdev? Or that the conversation will not lead to a viable solution. 
Stratustician
50%
50%
Stratustician,
 User Rank: Moderator
8/28/2014 | 9:25:10 AM
Re: Nah> "little value can come from this conversation"
I think there is definitely some value with really reminding folks that security is closely tied to application development.  While yes, many flaws will come up as part of a security attack, if you have strong code at the onset, especially if groups like these industry folks are able to start to identify "here are where we are seeing code vulnerabilities", it will hopefully lead to better code overall for these applications and reduce the risks.  You can't eliminate every potential threat, but at least you've narrowed the attack field by closing known vulnerabilities.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
8/28/2014 | 9:34:21 AM
Re: Nah> "little value can come from this conversation"
Well said,  @Stratustician. Narrowing down the field of code vulnerabiliies is definitely a valuable endeavor. 
Robert McDougal
50%
50%
Robert McDougal,
 User Rank: Ninja
8/28/2014 | 11:18:44 AM
Re: Nah
I must disagree with your assessment wholeheartedly. I can tell you from direct experience that secure coding practices are not taught in our colleges currently. What that leads to is developers who don't understand the importance of using stored procedures and prepared statements. This in turn leads to applications which have easily preventable vulnerabilities.


Secure coding will not fix all vulnerabilities but if done correctly it will prevent known vulnerabilities such as SQL injection or XSS from making its way into future applications.
macker490
50%
50%
macker490,
 User Rank: Ninja
8/29/2014 | 8:10:20 AM
cart and horse
remember: the O/S must protect the apps rather than the reverse.  you are always going to have a bad app someplace and if that can get an un-authorized update into the o/s you're toast.

you must start with a secure o/s and then proceed with the authentication of inputs particularly software but also data particularly anything financial or sensitive in nature.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
 User Rank: Strategist
8/28/2014 | 11:35:27 AM
Re: Nah
Good point about the Mitre, OWASP and other models. What I thought was particularly interseting with the IEEE report was that the recommendations come from real-world design flaws the participants themselves experienced -- Twitter, Google, etc. 
GonzSTL
50%
50%
GonzSTL,
 User Rank: Ninja
8/28/2014 | 2:22:29 PM
Secure Software Design
I received my CompSci degree quite a while back, and even then, the practice of input validation and communication comparmentalization was stressed in all my programming classes. My involvement in IT throughout the years encompasses software development, network architecture, server infrastructure, storage architecture, desktop standardization, virtualization, etc., so I can pretty much see things from a broad picture as well as from individual areas. In all those IT domains, the vast majority of exploits come from software design security flaws, and secondly, improper configurations.

What I believe is that there is tremendous pressure to deliver applications and technology, and sometimes that leads to shortcuts or bypassing certain aspects of development. If security considerations are part of the whole development process, and rigidly enforced from inception to delivery, then perhaps we would see a dramatic drop in exploitable software flaws. The question is, why are the shortcuts and bypasses allowed, and who allows them? Improper oversight seems to be the culprit, either due to lacck of knowledge or understanding, or faulty risk management in the development process. Simply stated, security considerations should be enforced from beginning to end.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
 User Rank: Strategist
8/28/2014 | 3:51:35 PM
Re: Secure Software Design
Great perspective, @GonzSTL. The go-to-market/release pressures are the biggest issue with much of app development, for sure. But you raise another good point about a lack of oversight and enforcement of good secure coding practices.
DarkReadingTim
50%
50%
DarkReadingTim,
 User Rank: Strategist
8/29/2014 | 9:32:37 AM
Re: Secure Software Design
Great to see our old friend Neil Daswani in Dark Reading again! One of the things that strikes me each year when OWASP posts its Top 10 Vulnerabilities list is how many of the vulnerabilities are old. I mean, *really* old like SQL injection and buffer overflow. I wonder, why do these well-known vulns continue to occur with such great frequency, and isn't there something that could be done at the development level to prevent them?
billkarwin
50%
50%
billkarwin,
 User Rank: Apprentice
8/30/2014 | 2:25:49 PM
Re: Secure Software Design
Tim, your question reminds me of a story my mother experienced. She joined a group of volunteers at the local college to help young people register to vote (in the US this is not automatic, you have to fill out a form when you turn 18). She and her group did this every year. One year, one of the other women complained, "We've been helping to register students to vote for ten years! When are they going to learn to do it themselves?" The rest of the group had to remind her that every year, a new crop of students turn 18, and those individuals had naturally never had to registered before.

This is also the reason that well-known security vulnerabilities continue to be a problem, even decades after the remedies were first understood. The developer community gets a new crop of newbie programmers every year. They have never had to think about secure programming while doing class assignments, and they're even less likely to have done so if they are self-taught.

Yes, there are well-known fixes for old security flaws. At least, they're well-known to us experienced programmers. It's our responsibility to spread the word and educate all developers to program in a secure way by default.
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
8/31/2014 | 10:50:34 AM
Re: Secure Software Design
Good analogies. To some extent I do feel that education does play a big role here from the start.(Education is always the key in many situations, the better informed you are the better decisions can be made) As in younger analysts should be cognizant of security measures.

Similar to how if you are born in the 90's you have a higher proclivity to technology and its apsects because you were born in that time period of rapid growth. (Born it it) Might be a little biased and I normally don't like using generalized statements but statistically speaking that is the case. 

If we look at this from a scrum standpoint using an adaptive method to vulnerability assessment is the most conducive to the environment. Vulnerabilities and attack vectors deviate and adapt so the ones that are coding software need to adapt their focus as well.
billkarwin
50%
50%
billkarwin,
 User Rank: Apprentice
9/1/2014 | 3:40:29 PM
Re: Secure Software Design
Ryan, if people born in the 90's have such a higher proclivity to technology, then why aren't they writing more secure code? I see both young and old individuals unwittingly writing vulnerable code. It has nothing to do with what year they were born, and everything to do with how aware they are of the risks and the consequences.

If they aren't educated to be aware of secure coding practices, then what's the alternative? Wait until they have a personal experience of being responsible for a security disaster because of the poor code they wrote?

Just like becoming a convert to using antivirus software, or becoming a convert to making backups diligently, after losing all one's files.
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
9/1/2014 | 5:13:04 PM
Re: Secure Software Design
I agree with you that education is the key here. The point I was trying to get across is just because someone is in the infancy of their career doesn't mean they don't have the theoretical components to write secure code. That is all. I was conveying that by the nature vs. nuture argument. If nature or experience is rivalled by nuture, which is the crux of the argument, than logically inexperienced (I mean this is in the sense of application) have the components to create secure code.

Your middle inquiry obviously uses reductio ad absurdum to berate the above statement. However, unfortunately you have heard of this being the case. With your example and with secure code. Many times its not until a breach happens where institutions decide there is a change needed to be made, and some software developers may be unaware of the hole in the first place. Hence new vulnerabilities. Is this due to a security flaw or a new attack strategy or maybe both? You cannot protect against something you are unaware of. (Heartbleed) It wasn't until this was discovered that a design flaw was even brought to light. This is highly unfortunate and our jobs as security professionals to try and show core value in security to other departments in the institution.

I agree with many of the points you make. Especially in the ways of education being the key. But to say that people that are surrounded by technology and have it ingrained in their daily lives opposed to a test group that has doesn't have it and is provided later in their lives is a frivolous and prideful notion.

I would say that security as a newer notion is valid, wherein people that are born in this generation will be the ones I speak of overall or the generation after. Security needs to a principle taught from a young age. Only than will people outside security be reached in its entirety.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
9/2/2014 | 8:23:17 AM
Re: Secure Software Design
@RyanSepe and @billkarwin, your back-and-forth about the generation gap in secure software development & education is great -- and extremely interesting. But why aren't app designers coming out of computer science programs with a deeper understanding of the importance of building secure applications?   Why isn't that a given?
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
9/2/2014 | 10:07:18 AM
Re: Secure Software Design
@Marilyn Cohodas, I think this comes down to specialization within education. Until recently there were very few collegiate programs that dealt specifically with cyber security and information security. I have seen more and more pop up in recent years. Information Technology and Computer Science is a generalized overview of the subject matter. Basically outlining the different aspects on a lower level. If you were to specialize in an area you would receive a higher level of understanding and knowledge base. If they took programs that specialized in app development, I am sure in the core curriculum that app security would be one of the courses given not just an individual unit of a singular course. This would allow a more in depth learning process and transfer over into development.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
9/2/2014 | 10:40:50 AM
Re: Secure Software Design
Good point, Ryan. Security awareness really does have to be more baked into our educational system, doesn't it. And not just at the high ed level where newbie programmers are drilled at the most secure way to design apps. I think security awareness  about threats should be started in elementary schools in the same way children are schooled to avoid putting themselves in harms way in the physical world..
JasonSachowski
50%
50%
JasonSachowski,
 User Rank: Author
9/3/2014 | 11:35:58 AM
Re: Secure Software Design
@billkarwin, i agree with the answer to your question about how writing secure code transcends to much more than just those born in the 90's.  For arguement sake, the same statement can be made about older and younger generations who have other collateral factors at play; such as they don't understand the technology or perhaps don't have the attention to detail.

@RyanSepe and @MarilynCohodas, I think you are right that we need to introduce the generations that follow us with the fundamentals of information/cyber/digital security much earlier than college or university.  Looking back at how fast technology has evolved in our lifetimes, one can only imagine what technologies the next generations will bring reinforces the fact that we have to educate eariler and make it a part of there every day lives.

I think software security in the education system today is looked at as somewhat of a security specialization and not a practice that is available in normal software development programs; in my experiences.  I will say that it's great to see the communities of InfoSec professionals actively involved in providing elementary schools with basic information/cyber/digital security but after this, it really needs to be continued as part of daily curriculum.


Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Oh, Bill? He's kind of old-school, but one of our best Cloud developers.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5216
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0. If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection. Upon seei...
CVE-2020-5217
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0. If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection. This could b...
CVE-2020-5223
PUBLISHED: 2020-01-23
In PrivateBin versions 1.2.0 before 1.2.2, and 1.3.0 before 1.3.2, a persistent XSS attack is possible. Under certain conditions, a user provided attachment file name can inject HTML leading to a persistent Cross-site scripting (XSS) vulnerability. The vulnerability has been fixed in PrivateBin v1.3...
CVE-2019-20399
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
CVE-2020-7915
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.