I would reference NIST Special Publication 800-218 and assess whether the team was following the recommendations outlined in the document. For example, Task PW.7.1 calls for determining whether code review or a code analysis tool is used. Specifically, it recommends the following implementation:
– Follow the organization’s policies or guidelines for when code review should be performed and how it should be conducted. This may include third-party code and reusable code modules written in-house.
– Follow the organization’s policies or guidelines for when code analysis should be performed and how it should be conducted.
In terms of auditing, I would review the policies referenced above and then assess if the team is following them. For example, if the company uses a code analysis tool to review code, I would look for reports from the tool that correspond to when the developer pushed code. If the organization did not have an automated analysis tool, I would observe a code review session and look for documentation of when past sessions occurred, e.g. comments on the pull request by the reviewer.
Per the SANS Application Development Technology and Tools paper, code reviews and peer reviews can help discover errors that cause input validation. The paper cites the following example which could be identified during a review. “If an URL is used as data type, it is also important to validate the existence of such an URL.” Failing to validate input could open up the app to cross-site scripting and similar attacks.
Hi Matthew, I like the point of view you mentioned from an auditing perspective as I do find it useful in looking over the reports from a code analysis tool and the comments that explain the code and the functions for the code is always great to observe for any mistakes or errors that could’ve been made.
It is never a bad idea to turn to NIST when auditing any technology. As long as companies are referring to their recommendations then that is a great starting point, so it makes sense to use that to check if the application was developed with secure coding practices. I also appreciate the note you have from SANS about having the code peer reviewed. When it comes to designing code like this it is very beneficial to get as many eyes as possible on the application being developed. It is not uncommon for the application teams to get tunnel vision and it usually only takes one outside perspective to get them thinking in a different direction.
I will refer to SDL practices according to the process:
1. Concept and planning
The purpose of this stage is to define the application concept and evaluate its viability. Includes developing a project plan, writing project requirements, and allocating human resources.
2. Architecture and design
The purpose of this stage is to design a product that meets the requirements. Includes modeling the application structure and its usage scenarios and choosing third-party components that can speed up development. The result of this stage is a design document.
3.Implementation
This is the stage at which an application is created. Includes writing the application code, debugging it, and producing stable builds suitable for testing.
4. Testing and bug fixing
The purpose of this stage is to discover and correct application errors. Includes running automatic and manual tests, identifying issues, and fixing them.
5. Release and maintenance
At this stage, an application goes live, with many instances running in a variety of environments. Eventually, new versions and patches become available, and some customers choose to upgrade, while others decide to keep the older versions.
6. End of life
“End of life” is the point when its developer no longer supports the software. Applications that store sensitive data may be subject to specific end-of-life regulations.
Hi Zijian,
I was able to read through the link you shared and I thought it was good approach to ensure secure coding practices. It’s important to start the cycle with proper concept and planning step where the team can discuss procedures and requirements of law and organization itself before moving further in the process. Personally, I think testing process is the most important step to understand if previous steps were taken in right direction or implementation was effective to secure coding.
Nicely done post. I find your fifth point to be incredibly important. Developing 100% secure code is almost impossible. However it does raise the question as to whether the team has a longterm remediation/patching plan? Security requires ongoing maintenance if the development team does not have a process in place for releasing timely patches for zero-days or other vulnerabilites that may be an indicator the development team did not actively consider security during the development process.
Hello Zijian. I like this, very well said; these are all fundamental concepts that need to be considered to determine if an applications development project team was using secure coding practices? I am, however, of the opinion that they are general recommendations and not specific, e.g., End of Life, what happens at this phase, and what is the end of life regulations required
According to SANS, You would determine the practices by looking at the validation of input data to see if buffer flow, script injection, sql injection, format strings,, vulnerabilities and countering SPAM is avoided. It is important that the application structure is written well including data handling, memory handling, error handling which would benefit again avoiding the vulnerabilities I just listed. Also, application should only call the external resources that is trusted. Valid data should be passed and received to avoid command injection, shell escape, cross-site scripting vulnerabilities. The access to data should be limited to needed program logic and processing.
University of Berkeley has good guideline to make sure organization’s team using secure coding practices. There are steps of the process including alignment with requirements, architecture and design, proper implementation, effective testing while deployment and maintenance.
To read: https://security.berkeley.edu/secure-coding-practice-guidelines
Thanks for sharing the link to UC Berkeley’s secure coding guidelines. This is a great resource. I like that they require a secure coding training plan for developers. Using guidelines from OWASP helps developers to understand common vulnerabilities introduced by bad development practices. This helps organizations to be more secure and helps prevent software bugs.
To determine if an application development project team is using secure coding practices, one would need first to understand the project development environment, for example, is the dev environment internally or externally facing and who has access to the environment? Next, is the development team aware of OWASP’s top ten application vulnerabilities and did they actively test for those vulnerabilities via static analysis and web app pen tests as part of the overall design? Furthermore, it would be critical to have a top-down approach to secure coding practices. Has the project manager allocated enough time to implement secure coding practices, or does the application development feel pressured to push the product out the door, thereby not adequately testing for flaws?
Thank you for your point of view. I agree with you that it is possible to question the specifics of the current team’s use of secure coding practices by understanding the project development environment and asking relevant questions. In addition, enough time is a good way to do this. On the other hand, this can be examined by looking at whether any cryptographic modules in use are compliant with FIPS 140-2 or equivalent.
Hello Kelly, excellent write-up; it is also good to note that the OWASP’s top ten application vulnerabilities, similar to the NIST SP 800 -218 and SANS requirements is also one of several parameters available as a benchmark to determine if an application development project team is using secure coding practices.
To determine software project team using secure coding practices or not, we can verify it by using Application development stages, we can measures that strengthen application security at specific stage.
Follow up the organizations policies and guideline to develop the secure code, for verify and determine need to analyze and test code each stage of the software development life cycle.
Before start web application code need to prepare list of security requirements for the project, it helpful to eliminate risk and write secure code to fix security issues earlier as possible as, also helpful to security awareness training to all project members.
Conduct threat modeling consist of identifying probable attack scenarios, this uncovers possible threat early which is useful to ensure application project coding is going right way.
Guides and checklists remind programmers of typical mistakes to be avoided, such as storing unencrypted passwords. Enforcing secure coding principles eliminates much trivial vulnerability and frees up time for other important tasks.
Static application scanning tools review newly written code and find potential weaknesses without having to run the application. Daily use of static scanning tools uncovers mistakes before they can make their way into application builds.
Dynamic application scanner tools expose vulnerabilities by simulating hacker attacks at runtime. To reduce false positives, you can use a combined approach.
Fuzz testing involves generating random inputs based on custom patterns and checking whether the application can handle such inputs properly.
Real attackers exploit environment configuration errors and vulnerabilities. Security monitoring must cover the entire system, not just the application. Such monitoring improves the overall security of your application.
Security checks must be repeated on a regular basis because new types of vulnerabilities are being discovered at a steady rate. Regular checks protect your application from newly discovered vulnerabilities
Hello Mohammed, this is very detailed in stating the steps to follow. My observation is that these answer the question of what to do to determine… and not how to choose if an applications development project team was using secure coding practices?
If the development team was developing web applications I would go through the OWASP secure coding practices checklist. The categories in the list contain criteria input validation, output encoding, authentication and password management, session management, access control, access control, cryptographic controls, and many other items. The goal is to maintain confidentiality, availability, and integrity.
The Open web application security project refers security coding principles that should be implemented. This includes a checklist for input validation, output encoding, session management, authentication and password management, access control, cryptographic practices, error handling and logging, data protection, communications security, system configuration, database security, file management, and memory management.It goes in depth into each section for the checklist and has guidelines on what to do. For example it has the checklist for input validation set as :
*Conduct all data validation on a trusted system
*validate range, length, expected data types, white list
*encode data to a common character set before validating
*specify proper character sets such as UTF-8
*All validation failures should result in input injection.
I pretty much went the same route. I would start with the OWASP checklist as well, it’s comprehensive and covers pretty much everything that needs to be tested, it even has the encoding type in the checklist as you mentioned, and that is something that is often forgotten,
Wilmer, I had a pretty similar thought process as you when approaching this question. While everybody had pretty good approaches to determine whether or not the application team is/isn’t using secure coding practices, I feel as if OWASP is the ideal place to start, mainly because going through the checklist process seems like a very straight forward and reliable way to determine compliance.
If I were checking if an applications development project team was using secure coding practices, I would first examine their process during the testing phase. The project team should be running checks against their application for the most common vulnerabilities as outlined by SANS, such as SQL injections, buffer overflows, format strings etc. If the team isn’t checking for these vulnerabilities, then the most likely were not considering this during the planning and development phases of the application. The secure coding practices need to be followed while the code for the application is in development.
I like your response because I think that the testing phases are the most important phases in the security development lifecycle. Security testing helps expose code vulnerabilities such as user privilege issues, which is a type of vulnerability that is one of the main vectors of cyberattacks.
There is a lot of practices to determine if an application development project was using secure coding practices such as
Protecting database from SQL Injection
Encoding data before using it
Validating Input data before using it or store it
Establishing Identity ( Access Management/Identity Management)
Segmenting your network
if I am ask to examine if an applications development project team was basically make use of secure coding practices, then I would first determine their process during the testing phase. The project team should be establishing parameters against their application for the most common vulnerabilities as being identified by SANS, such as SQL injections, buffer overflows, format strings . Should the team is not establishing parameters for these vulnerabilities, then it looks likely that they were not establishing this during the planning and development phases of the application. The secure coding practices need to be strictly followed while the code for the application is in development.
A critical system is a system that has the job of protecting whatever we’re protecting. This can be intercontinental ballistic missiles, the national power grid, personally identifiable information (PII), cash, intellectual property, or the plans to the Death Star. But a critical system is also any other system capable of interacting with that system. This can be unrelated processes in the OS, hardware such as printers, or external unrelated systems capable of touching that system. When we look at the security of a system, we have to consider everything that touches it no matter how trivial or seemingly low risk.
The use of secure coding practices for coding is well documented. In order to determine if the application development project team is using secure coding practices, this can be determined through a number of techniques that perform this operation. First, data validation checks help protect Web applications from cyber attacks, and the length and date range of a piece of data is well documented. Also, see if any cryptographic modules used are compliant with FIPS 140-2 or equivalent. Also, check to see if a TLS connection is used to protect the data in transit. On the other hand, you can outsource and have a professional team check if the application development project team is using secure coding practices.
How would you determine if an applications development project team was using secure coding practices?
Using secure coding practices is patching a system when it needs to be. Patch and vulnerability management is focused on identifying risk and enabling systems to stay up to date. However, secure coding practices include security by design, password management, access control, error handling and logging, system configuration, threat modeling, cryptographic practices, and input validation and encoding. Passwords need to be enforced to be the length and meet the complexity requirements. Also, it is important to disable a password after unsuccessful login attempts have occurred.
Organizations can limit privileges and restrict access to secure data to only users to absolutely need it/are necessary. Ensure least privilege approach is followed if an organization is utilizing it.
Error handling attempts to catch errors in code before they result in a failure. Logging documents errors so developers can mitigate their cause.
How would you determine if an applications development project team was using secure coding practices?
Starting from application development there would have to be established practices between any vendors or teams who work on developing source code for the application in use. Contracts must be reviewed with stakeholders before applying best practices and be established from an organization-accepted standard based on the industry. SANS and OWASP provide cheat sheets/checklists that can be established before development even starts in order to set the premise that the application needs to be built with security in mind. These contracts would be reviewed initially to ensure that project teams have references to practices.
After contracts/policy has been established I would commit a peer-review or code review board (depending on the scope of the application) to periodically analyze and compare new source code to check for security flaws. In the SANS reading it states that in cases where code is not possible to manually review with peers (due to source code increasing in size) then it would be a requirement for developers to employ tools such as RATS, Flawfinder, Pscan, Splint, ESC/JAVA and Fortify. These review boards would have to document each meeting as evidence that they are reviewing source code as evidence that these reviews are occurring.
Michael,
great points regarding security being in the initial phase of development before any code is even written. Thank you for supplying the links to the cheatsheets, I actually looked over the OWASP example for quite a bit and found it rather insightful.
To determine if an applications development project team was using secure coding practices, I would compare the current practice with the provisions of NIST SP. 800-218, which serves as the guide for fast software development. Following these practices helps software producers ensure that the software they develop is well secured.
NIST 800 – 218 Secure Software Development 2 3 Framework (SSDF) Version 1.1:recommends the under-listed as the benchmark for assessing the secure coding of any software development
1. Define the Security Requirements for Software Development (PO.1):
2. Implement Roles and Responsibilities (PO.2):
3. Implement Supporting Toolchains (PO.3)
4. Define and Use Criteria for Software Security Checks (PO.4):
5. Implement and Maintain Secure Environments for Software Development (PO.5):
6. Protect All Forms of Code from Unauthorized Access and Tampering (PS.1):
7. Provide a Mechanism for Verifying Software Release Integrity (PS.2):
8. Archive and Protect Each Software Release (PS.3):
9. Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1)
10. Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2):
11. Verify Third-Party Software Complies with Security Requirements (PW.3):
12. Create Source Code by Adhering to Secure Coding Practices (PW.5):
13. Configure the Integrated Development Environment, Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6)
14. Review and Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7):
15. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8):
16. Configure Software to Have Secure Settings by Default (PW.9):
17. Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1)
18. Assess, Prioritize, and Remediate Vulnerabilities (RV.2):
19. Analyze Vulnerabilities to Identify Their Root Causes (RV.3):
Hi Olayinka,
Great job tying this question into the NIST SP 800! This was a great reflection for me personally to compare this week’s readings with NIST-based audit work.
How would you determine if an applications development project team was using secure coding practices?
One of the simplest approaches as a starting point would be to ask a random person on the development team when their next code review is, and how often they are, just to get a feel for how aware they are of secure coding practices in general. If they are clueless it is probably a bad sign. Then I would ask if they utilize any code scanners like WebGoat, and if they perform unit testing for input validation. Another useful question to ask for evidence of is whether or not the organization has their applications pentested or not, especially by an external renowned third party consultancy that will not overlook anything or have any bias.
Hello Antonio,
That’s a great post. That sure is a really good idea to interview the team members to identify if they are aware of the process or not. As well as I would say to interview the managers as well to identify if only the team members many not be aware of certain process or if the certain process is not part of the development of that application. Also, that was a great idea to have the testing completed by the third party to avoid h bias issues an if the have overlooked anything.
To determined if an applications development project team was using secure coding practices the companies can perform a testing during and after the application is being developed to ensure there are no flaws within the application that are part of the secure coding practices. They can ensure the inputs that are being enter into the application is valid and it doesn’t accept any inputs that the application shouldn’t accept. The data that is accessible are what the user is being granted access to. Also, the application is not providing user with additional information then it should as an if there is an error then the application should only prompt the error code and not an detailed explanation of the issue.
Performing periodic penetration tests or web application assessments is a good way to determine if your application development team is using secure coding practices. Both processes can be performed either internally or by a third-party vendor. After a listing of applications for review is identified, test procedures can be developed to conclude whether each application is subject to some kind of threat, such as SQL injection attacks. After the test is performed, remediation plans can be established for any findings that are identified.
There are numerous ways through an audit that can determine if a development team is indeed following secure coding procedures. First and foremost, checking if a network/application diagram is maintained will give auditors insight that the team has proper knowledge and comprehension on how their systems work and how data flows. Another example ties into database/access control. An auditor should assess privileges given to team personnel in terms of who has read/write access to source code, and the database as a whole. This should be confirmed through authorization and authentication auditing validation, through evidence in the form of screenshots, for instance. Another way I would audit a team regarding secure coding practices is to review if they are following correct input validation procedures, as well as reviewing the output code. As a whole, there also should be a secure software development lifecycle (SSDLC) policy which I would also assess.
Great post Lauren, It’s also important to ensure developers do not have the ability to deploy code to production. If they do require production access, it should be limited to read-only or segregation of duties (SoD) controls should be applied to ensure access is appropriate. Securing production access adds and additional layer of security and compliments the process monitoring and maintaining access in non-production environments.
How would you determine if an applications development project team was using secure coding practices?
There are tools that you can use to scan source code. You can interview and ask questions to see if the team writing the code followed certain practices. Both of these methods includes looking for specific patterns or practices that are conducive to secure coding. Alternatively, you also search for anti-patterns or bad practices that developers should not be doing as they write code.
A healthy SDLC process will have security focus built into it – I believe that secure coding practices should not be something ‘we check for’ as much as it is ‘how we do our coding’. If only securely coded software is deemed acceptable, then that should be the product of the dev team. DevSecOps is a way of doing things vs doing DevOps and adding in a Security check.
Good point on interviewing the team. This can be done during any aspect of the development process – pre, during, and post-development. You can set expectations in the pre-development stage and make sure your project team is following them through those interviews and audits.
How would you determine if an applications development project team was using secure coding practices?
As learned in the SANS reading it is a good practice to employ code reviews and peer-reviews to make sure that the application program has been coded according to the best established practices. Assuming that the peer-review is a part of application design and development process, reviewing code for Security flaws also should be added to that process.
In the cases where it is humanly impossible to scan the code for flaws, source
code scanners and testing tools can be used. The popular code scanners include
RATS (Rough Auditing Tool for Security), Flawfinder, Pscan, Splint (Secure
Programming Lint), ESC/JAVA (Extended Static Checking for Java).
There are also other tools like AtStake WebProxy, SPIKE Proxy, WebserverFP,
KSES, Mieliekoek.pl, Sleuth, Webgoat and AppScan, which are useful in testing
the vulnerabilities in the application. Among these tools, Webgoat is an open
source tool that is aimed at educating developers on the most common web
application security and design flaws using practical exercises
Depending on the development stage, there are certain steps you can take.
In pre-development and planning, you can set expectations for the team regarding the secure coding practices that should be followed during the project.
During development, you can also implement code reviews, interviews, and auditing. This is to hold the team accountable to secure coding practices such as security by design.
In post-production, you can scan the source code for vulnerabilities and flaws. You can also perform peer analyses.
In order to determine if an applications development project team was using secure coding practices, I would probably begin by referring to OWASP’s Secure Coding Practices Quick Reference Guide. The reason I would start with this is because it is a simple checklist, yet comprehensive enough to determine if secure practices are being followed or not. Based on results derived from the checklist, it would be easy enough to determine if best practices were being put in place or if additional work was necessary.
Excellent analysis .However, you need to understand that in order for applications to be designed and implemented with proper security requirements, secure coding practices and a focus on security risks must be integrated into day-to-day operations and the development processes. Application developers must complete secure coding requirements regardless of the device used for programming.
I came across OWASP secure coding practices quick reference guide and these is a good starting point to see if your project team was using secure coding practices. It references a checklist and some of the checklist includes conducting all data validation on a trusted system and identifying all data sources and classify them into trusted and untrusted. Just to name a few. With having a checklist at hand, puts you in a better position to see if your team is using secure coding practices. https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
Great analysis but I beg to differ in certain extent due to the fact that Software security is important because it helps ensure that software is safeguarded against potential vulnerabilities, errors, or bugs. A key part of that defense is the use of secure coding standards. What’s more, secure coding applies to every development team — regardless of whether it’s code for mobile devices, personal computers, servers.
And you can take that guide to use it in code review / peer review boards in order to follow industry standards! SANS & OWASP have great resources that are entirely free for organizations to harden their source code. Which is even better for the industry since business hates things that cost a lot of money – luckily the cyber community is typically open about best practices since in terms of security it’s actually better. Which is actually why a lot of proprietary encryption techniques aren’t used because it’s harder to ensure encryption actually works if nobody can test it.
Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user-controlled files.
Integrate secure coding principles into SDLC components by providing a general description of how the secure coding principles are addressed in Architecture and Design documents. If a secure coding principle is not applicable to the project, this should be explicitly documented along with a brief explanation. https://security.berkeley.edu/secure-coding-practice-guidelines
I would reference NIST Special Publication 800-218 and assess whether the team was following the recommendations outlined in the document. For example, Task PW.7.1 calls for determining whether code review or a code analysis tool is used. Specifically, it recommends the following implementation:
– Follow the organization’s policies or guidelines for when code review should be performed and how it should be conducted. This may include third-party code and reusable code modules written in-house.
– Follow the organization’s policies or guidelines for when code analysis should be performed and how it should be conducted.
In terms of auditing, I would review the policies referenced above and then assess if the team is following them. For example, if the company uses a code analysis tool to review code, I would look for reports from the tool that correspond to when the developer pushed code. If the organization did not have an automated analysis tool, I would observe a code review session and look for documentation of when past sessions occurred, e.g. comments on the pull request by the reviewer.
Per the SANS Application Development Technology and Tools paper, code reviews and peer reviews can help discover errors that cause input validation. The paper cites the following example which could be identified during a review. “If an URL is used as data type, it is also important to validate the existence of such an URL.” Failing to validate input could open up the app to cross-site scripting and similar attacks.
Hi Matthew, I like the point of view you mentioned from an auditing perspective as I do find it useful in looking over the reports from a code analysis tool and the comments that explain the code and the functions for the code is always great to observe for any mistakes or errors that could’ve been made.
Matt,
It is never a bad idea to turn to NIST when auditing any technology. As long as companies are referring to their recommendations then that is a great starting point, so it makes sense to use that to check if the application was developed with secure coding practices. I also appreciate the note you have from SANS about having the code peer reviewed. When it comes to designing code like this it is very beneficial to get as many eyes as possible on the application being developed. It is not uncommon for the application teams to get tunnel vision and it usually only takes one outside perspective to get them thinking in a different direction.
I will refer to SDL practices according to the process:
1. Concept and planning
The purpose of this stage is to define the application concept and evaluate its viability. Includes developing a project plan, writing project requirements, and allocating human resources.
2. Architecture and design
The purpose of this stage is to design a product that meets the requirements. Includes modeling the application structure and its usage scenarios and choosing third-party components that can speed up development. The result of this stage is a design document.
3.Implementation
This is the stage at which an application is created. Includes writing the application code, debugging it, and producing stable builds suitable for testing.
4. Testing and bug fixing
The purpose of this stage is to discover and correct application errors. Includes running automatic and manual tests, identifying issues, and fixing them.
5. Release and maintenance
At this stage, an application goes live, with many instances running in a variety of environments. Eventually, new versions and patches become available, and some customers choose to upgrade, while others decide to keep the older versions.
6. End of life
“End of life” is the point when its developer no longer supports the software. Applications that store sensitive data may be subject to specific end-of-life regulations.
https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/
Hi Zijian,
I was able to read through the link you shared and I thought it was good approach to ensure secure coding practices. It’s important to start the cycle with proper concept and planning step where the team can discuss procedures and requirements of law and organization itself before moving further in the process. Personally, I think testing process is the most important step to understand if previous steps were taken in right direction or implementation was effective to secure coding.
Hi Zijian,
Nicely done post. I find your fifth point to be incredibly important. Developing 100% secure code is almost impossible. However it does raise the question as to whether the team has a longterm remediation/patching plan? Security requires ongoing maintenance if the development team does not have a process in place for releasing timely patches for zero-days or other vulnerabilites that may be an indicator the development team did not actively consider security during the development process.
Kelly
Hello Zijian. I like this, very well said; these are all fundamental concepts that need to be considered to determine if an applications development project team was using secure coding practices? I am, however, of the opinion that they are general recommendations and not specific, e.g., End of Life, what happens at this phase, and what is the end of life regulations required
According to SANS, You would determine the practices by looking at the validation of input data to see if buffer flow, script injection, sql injection, format strings,, vulnerabilities and countering SPAM is avoided. It is important that the application structure is written well including data handling, memory handling, error handling which would benefit again avoiding the vulnerabilities I just listed. Also, application should only call the external resources that is trusted. Valid data should be passed and received to avoid command injection, shell escape, cross-site scripting vulnerabilities. The access to data should be limited to needed program logic and processing.
University of Berkeley has good guideline to make sure organization’s team using secure coding practices. There are steps of the process including alignment with requirements, architecture and design, proper implementation, effective testing while deployment and maintenance.
To read: https://security.berkeley.edu/secure-coding-practice-guidelines
Thanks for sharing the link to UC Berkeley’s secure coding guidelines. This is a great resource. I like that they require a secure coding training plan for developers. Using guidelines from OWASP helps developers to understand common vulnerabilities introduced by bad development practices. This helps organizations to be more secure and helps prevent software bugs.
To determine if an application development project team is using secure coding practices, one would need first to understand the project development environment, for example, is the dev environment internally or externally facing and who has access to the environment? Next, is the development team aware of OWASP’s top ten application vulnerabilities and did they actively test for those vulnerabilities via static analysis and web app pen tests as part of the overall design? Furthermore, it would be critical to have a top-down approach to secure coding practices. Has the project manager allocated enough time to implement secure coding practices, or does the application development feel pressured to push the product out the door, thereby not adequately testing for flaws?
Hi Kelly,
Thank you for your point of view. I agree with you that it is possible to question the specifics of the current team’s use of secure coding practices by understanding the project development environment and asking relevant questions. In addition, enough time is a good way to do this. On the other hand, this can be examined by looking at whether any cryptographic modules in use are compliant with FIPS 140-2 or equivalent.
Hello Kelly, excellent write-up; it is also good to note that the OWASP’s top ten application vulnerabilities, similar to the NIST SP 800 -218 and SANS requirements is also one of several parameters available as a benchmark to determine if an application development project team is using secure coding practices.
To determine software project team using secure coding practices or not, we can verify it by using Application development stages, we can measures that strengthen application security at specific stage.
Follow up the organizations policies and guideline to develop the secure code, for verify and determine need to analyze and test code each stage of the software development life cycle.
Before start web application code need to prepare list of security requirements for the project, it helpful to eliminate risk and write secure code to fix security issues earlier as possible as, also helpful to security awareness training to all project members.
Conduct threat modeling consist of identifying probable attack scenarios, this uncovers possible threat early which is useful to ensure application project coding is going right way.
Guides and checklists remind programmers of typical mistakes to be avoided, such as storing unencrypted passwords. Enforcing secure coding principles eliminates much trivial vulnerability and frees up time for other important tasks.
Static application scanning tools review newly written code and find potential weaknesses without having to run the application. Daily use of static scanning tools uncovers mistakes before they can make their way into application builds.
Dynamic application scanner tools expose vulnerabilities by simulating hacker attacks at runtime. To reduce false positives, you can use a combined approach.
Fuzz testing involves generating random inputs based on custom patterns and checking whether the application can handle such inputs properly.
Real attackers exploit environment configuration errors and vulnerabilities. Security monitoring must cover the entire system, not just the application. Such monitoring improves the overall security of your application.
Security checks must be repeated on a regular basis because new types of vulnerabilities are being discovered at a steady rate. Regular checks protect your application from newly discovered vulnerabilities
Hello Mohammed, this is very detailed in stating the steps to follow. My observation is that these answer the question of what to do to determine… and not how to choose if an applications development project team was using secure coding practices?
If the development team was developing web applications I would go through the OWASP secure coding practices checklist. The categories in the list contain criteria input validation, output encoding, authentication and password management, session management, access control, access control, cryptographic controls, and many other items. The goal is to maintain confidentiality, availability, and integrity.
The Open web application security project refers security coding principles that should be implemented. This includes a checklist for input validation, output encoding, session management, authentication and password management, access control, cryptographic practices, error handling and logging, data protection, communications security, system configuration, database security, file management, and memory management.It goes in depth into each section for the checklist and has guidelines on what to do. For example it has the checklist for input validation set as :
*Conduct all data validation on a trusted system
*validate range, length, expected data types, white list
*encode data to a common character set before validating
*specify proper character sets such as UTF-8
*All validation failures should result in input injection.
Hi Wilmer,
I pretty much went the same route. I would start with the OWASP checklist as well, it’s comprehensive and covers pretty much everything that needs to be tested, it even has the encoding type in the checklist as you mentioned, and that is something that is often forgotten,
Wilmer, I had a pretty similar thought process as you when approaching this question. While everybody had pretty good approaches to determine whether or not the application team is/isn’t using secure coding practices, I feel as if OWASP is the ideal place to start, mainly because going through the checklist process seems like a very straight forward and reliable way to determine compliance.
If I were checking if an applications development project team was using secure coding practices, I would first examine their process during the testing phase. The project team should be running checks against their application for the most common vulnerabilities as outlined by SANS, such as SQL injections, buffer overflows, format strings etc. If the team isn’t checking for these vulnerabilities, then the most likely were not considering this during the planning and development phases of the application. The secure coding practices need to be followed while the code for the application is in development.
Ryan,
I like your response because I think that the testing phases are the most important phases in the security development lifecycle. Security testing helps expose code vulnerabilities such as user privilege issues, which is a type of vulnerability that is one of the main vectors of cyberattacks.
-Mike
There is a lot of practices to determine if an application development project was using secure coding practices such as
Protecting database from SQL Injection
Encoding data before using it
Validating Input data before using it or store it
Establishing Identity ( Access Management/Identity Management)
Segmenting your network
if I am ask to examine if an applications development project team was basically make use of secure coding practices, then I would first determine their process during the testing phase. The project team should be establishing parameters against their application for the most common vulnerabilities as being identified by SANS, such as SQL injections, buffer overflows, format strings . Should the team is not establishing parameters for these vulnerabilities, then it looks likely that they were not establishing this during the planning and development phases of the application. The secure coding practices need to be strictly followed while the code for the application is in development.
A critical system is a system that has the job of protecting whatever we’re protecting. This can be intercontinental ballistic missiles, the national power grid, personally identifiable information (PII), cash, intellectual property, or the plans to the Death Star. But a critical system is also any other system capable of interacting with that system. This can be unrelated processes in the OS, hardware such as printers, or external unrelated systems capable of touching that system. When we look at the security of a system, we have to consider everything that touches it no matter how trivial or seemingly low risk.
The use of secure coding practices for coding is well documented. In order to determine if the application development project team is using secure coding practices, this can be determined through a number of techniques that perform this operation. First, data validation checks help protect Web applications from cyber attacks, and the length and date range of a piece of data is well documented. Also, see if any cryptographic modules used are compliant with FIPS 140-2 or equivalent. Also, check to see if a TLS connection is used to protect the data in transit. On the other hand, you can outsource and have a professional team check if the application development project team is using secure coding practices.
How would you determine if an applications development project team was using secure coding practices?
Using secure coding practices is patching a system when it needs to be. Patch and vulnerability management is focused on identifying risk and enabling systems to stay up to date. However, secure coding practices include security by design, password management, access control, error handling and logging, system configuration, threat modeling, cryptographic practices, and input validation and encoding. Passwords need to be enforced to be the length and meet the complexity requirements. Also, it is important to disable a password after unsuccessful login attempts have occurred.
Organizations can limit privileges and restrict access to secure data to only users to absolutely need it/are necessary. Ensure least privilege approach is followed if an organization is utilizing it.
Error handling attempts to catch errors in code before they result in a failure. Logging documents errors so developers can mitigate their cause.
How would you determine if an applications development project team was using secure coding practices?
Starting from application development there would have to be established practices between any vendors or teams who work on developing source code for the application in use. Contracts must be reviewed with stakeholders before applying best practices and be established from an organization-accepted standard based on the industry. SANS and OWASP provide cheat sheets/checklists that can be established before development even starts in order to set the premise that the application needs to be built with security in mind. These contracts would be reviewed initially to ensure that project teams have references to practices.
After contracts/policy has been established I would commit a peer-review or code review board (depending on the scope of the application) to periodically analyze and compare new source code to check for security flaws. In the SANS reading it states that in cases where code is not possible to manually review with peers (due to source code increasing in size) then it would be a requirement for developers to employ tools such as RATS, Flawfinder, Pscan, Splint, ESC/JAVA and Fortify. These review boards would have to document each meeting as evidence that they are reviewing source code as evidence that these reviews are occurring.
OWASP example:
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
SANS example:
https://www.sans.org/cloud-security/securing-web-application-technologies/
Michael,
great points regarding security being in the initial phase of development before any code is even written. Thank you for supplying the links to the cheatsheets, I actually looked over the OWASP example for quite a bit and found it rather insightful.
To determine if an applications development project team was using secure coding practices, I would compare the current practice with the provisions of NIST SP. 800-218, which serves as the guide for fast software development. Following these practices helps software producers ensure that the software they develop is well secured.
NIST 800 – 218 Secure Software Development 2 3 Framework (SSDF) Version 1.1:recommends the under-listed as the benchmark for assessing the secure coding of any software development
1. Define the Security Requirements for Software Development (PO.1):
2. Implement Roles and Responsibilities (PO.2):
3. Implement Supporting Toolchains (PO.3)
4. Define and Use Criteria for Software Security Checks (PO.4):
5. Implement and Maintain Secure Environments for Software Development (PO.5):
6. Protect All Forms of Code from Unauthorized Access and Tampering (PS.1):
7. Provide a Mechanism for Verifying Software Release Integrity (PS.2):
8. Archive and Protect Each Software Release (PS.3):
9. Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1)
10. Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2):
11. Verify Third-Party Software Complies with Security Requirements (PW.3):
12. Create Source Code by Adhering to Secure Coding Practices (PW.5):
13. Configure the Integrated Development Environment, Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6)
14. Review and Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7):
15. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8):
16. Configure Software to Have Secure Settings by Default (PW.9):
17. Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1)
18. Assess, Prioritize, and Remediate Vulnerabilities (RV.2):
19. Analyze Vulnerabilities to Identify Their Root Causes (RV.3):
Reference:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218-draft.pdf
Hi Olayinka,
Great job tying this question into the NIST SP 800! This was a great reflection for me personally to compare this week’s readings with NIST-based audit work.
How would you determine if an applications development project team was using secure coding practices?
One of the simplest approaches as a starting point would be to ask a random person on the development team when their next code review is, and how often they are, just to get a feel for how aware they are of secure coding practices in general. If they are clueless it is probably a bad sign. Then I would ask if they utilize any code scanners like WebGoat, and if they perform unit testing for input validation. Another useful question to ask for evidence of is whether or not the organization has their applications pentested or not, especially by an external renowned third party consultancy that will not overlook anything or have any bias.
Hello Antonio,
That’s a great post. That sure is a really good idea to interview the team members to identify if they are aware of the process or not. As well as I would say to interview the managers as well to identify if only the team members many not be aware of certain process or if the certain process is not part of the development of that application. Also, that was a great idea to have the testing completed by the third party to avoid h bias issues an if the have overlooked anything.
To determined if an applications development project team was using secure coding practices the companies can perform a testing during and after the application is being developed to ensure there are no flaws within the application that are part of the secure coding practices. They can ensure the inputs that are being enter into the application is valid and it doesn’t accept any inputs that the application shouldn’t accept. The data that is accessible are what the user is being granted access to. Also, the application is not providing user with additional information then it should as an if there is an error then the application should only prompt the error code and not an detailed explanation of the issue.
Performing periodic penetration tests or web application assessments is a good way to determine if your application development team is using secure coding practices. Both processes can be performed either internally or by a third-party vendor. After a listing of applications for review is identified, test procedures can be developed to conclude whether each application is subject to some kind of threat, such as SQL injection attacks. After the test is performed, remediation plans can be established for any findings that are identified.
There are numerous ways through an audit that can determine if a development team is indeed following secure coding procedures. First and foremost, checking if a network/application diagram is maintained will give auditors insight that the team has proper knowledge and comprehension on how their systems work and how data flows. Another example ties into database/access control. An auditor should assess privileges given to team personnel in terms of who has read/write access to source code, and the database as a whole. This should be confirmed through authorization and authentication auditing validation, through evidence in the form of screenshots, for instance. Another way I would audit a team regarding secure coding practices is to review if they are following correct input validation procedures, as well as reviewing the output code. As a whole, there also should be a secure software development lifecycle (SSDLC) policy which I would also assess.
Great post Lauren, It’s also important to ensure developers do not have the ability to deploy code to production. If they do require production access, it should be limited to read-only or segregation of duties (SoD) controls should be applied to ensure access is appropriate. Securing production access adds and additional layer of security and compliments the process monitoring and maintaining access in non-production environments.
How would you determine if an applications development project team was using secure coding practices?
There are tools that you can use to scan source code. You can interview and ask questions to see if the team writing the code followed certain practices. Both of these methods includes looking for specific patterns or practices that are conducive to secure coding. Alternatively, you also search for anti-patterns or bad practices that developers should not be doing as they write code.
A healthy SDLC process will have security focus built into it – I believe that secure coding practices should not be something ‘we check for’ as much as it is ‘how we do our coding’. If only securely coded software is deemed acceptable, then that should be the product of the dev team. DevSecOps is a way of doing things vs doing DevOps and adding in a Security check.
Great point about a healthy SDLC having security focus built into it
Hi Richard,
Good point on interviewing the team. This can be done during any aspect of the development process – pre, during, and post-development. You can set expectations in the pre-development stage and make sure your project team is following them through those interviews and audits.
How would you determine if an applications development project team was using secure coding practices?
As learned in the SANS reading it is a good practice to employ code reviews and peer-reviews to make sure that the application program has been coded according to the best established practices. Assuming that the peer-review is a part of application design and development process, reviewing code for Security flaws also should be added to that process.
In the cases where it is humanly impossible to scan the code for flaws, source
code scanners and testing tools can be used. The popular code scanners include
RATS (Rough Auditing Tool for Security), Flawfinder, Pscan, Splint (Secure
Programming Lint), ESC/JAVA (Extended Static Checking for Java).
There are also other tools like AtStake WebProxy, SPIKE Proxy, WebserverFP,
KSES, Mieliekoek.pl, Sleuth, Webgoat and AppScan, which are useful in testing
the vulnerabilities in the application. Among these tools, Webgoat is an open
source tool that is aimed at educating developers on the most common web
application security and design flaws using practical exercises
Depending on the development stage, there are certain steps you can take.
In pre-development and planning, you can set expectations for the team regarding the secure coding practices that should be followed during the project.
During development, you can also implement code reviews, interviews, and auditing. This is to hold the team accountable to secure coding practices such as security by design.
In post-production, you can scan the source code for vulnerabilities and flaws. You can also perform peer analyses.
Hey Madalyn,
Great points and thanks for pointing out the multiple times to be able to check for secure coding practices. Have you encountered this at your job?
In order to determine if an applications development project team was using secure coding practices, I would probably begin by referring to OWASP’s Secure Coding Practices Quick Reference Guide. The reason I would start with this is because it is a simple checklist, yet comprehensive enough to determine if secure practices are being followed or not. Based on results derived from the checklist, it would be easy enough to determine if best practices were being put in place or if additional work was necessary.
Excellent analysis .However, you need to understand that in order for applications to be designed and implemented with proper security requirements, secure coding practices and a focus on security risks must be integrated into day-to-day operations and the development processes. Application developers must complete secure coding requirements regardless of the device used for programming.
I came across OWASP secure coding practices quick reference guide and these is a good starting point to see if your project team was using secure coding practices. It references a checklist and some of the checklist includes conducting all data validation on a trusted system and identifying all data sources and classify them into trusted and untrusted. Just to name a few. With having a checklist at hand, puts you in a better position to see if your team is using secure coding practices.
https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
Great analysis but I beg to differ in certain extent due to the fact that Software security is important because it helps ensure that software is safeguarded against potential vulnerabilities, errors, or bugs. A key part of that defense is the use of secure coding standards. What’s more, secure coding applies to every development team — regardless of whether it’s code for mobile devices, personal computers, servers.
Corey,
And you can take that guide to use it in code review / peer review boards in order to follow industry standards! SANS & OWASP have great resources that are entirely free for organizations to harden their source code. Which is even better for the industry since business hates things that cost a lot of money – luckily the cyber community is typically open about best practices since in terms of security it’s actually better. Which is actually why a lot of proprietary encryption techniques aren’t used because it’s harder to ensure encryption actually works if nobody can test it.
Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user-controlled files.
Integrate secure coding principles into SDLC components by providing a general description of how the secure coding principles are addressed in Architecture and Design documents. If a secure coding principle is not applicable to the project, this should be explicitly documented along with a brief explanation.
https://security.berkeley.edu/secure-coding-practice-guidelines