This document is designed to give you a brief overview of some of the security-related processes that occur during the development of the Telligent Evolution Platform. It also describes the threats that are tested for in the Telligent Evolution platform. Lastly, it details part of the incidence response that will occur if vulnerabilities are discovered.
In order to help ensure that the platform is being developed in a secure way, the product development team follows the Microsoft Software Development Lifecycle-Agile (SDL-Agile) guidelines. By following SDL-Agile, the team is focused on security during every iteration of development. Similarly, the up-front design of new features considers potential security threats.
One of the steps that have been taken to help ensure the security of code that is constructed is the development of an internal set of security guidelines for code. The development team has a set of guidelines that each member follows as they create new code. The guidelines are extensions to the Web application rules found in the SDL-Agile document. During weekly security assessments, new code is checked for compliance with these security guidelines. This set of guidelines is also updated whenever new threats are discovered that can impact the Telligent Evolution platform.
Every week, new code is examined for any new vulnerability that may have been introduced. The details of the assessment are explained further in the Continuous security assessments section. During this process, code is manually reviewed for security bugs that could have been introduced. This process is often done more than once per iteration, which exceeds the requirements outlined in SDL-Agile.
In order to understand the threats that impact a new feature, models are constructed during the design of the feature. The Microsoft Threat Modeling tool is often used for threat modeling. However, attack trees and other modeling tools may be used in the future. Aside from modeling, much of the up-front design of new features involves a discussion of security concerns and potential threats.
The Quality Assurance team not only performs checks for authorization threats, but also performs passive vulnerability scanning. For each test case that they complete, they are also performing a passive vulnerability scan in the background. The scanning is configured to detect a wide range of threat types. Each of the reports is analyzed for new security vulnerabilities, which are ticketed and fixed.
There are several scanners that are used to detect vulnerabilities in the Telligent Evolution platform. Telligent uses both open source and commercial scanner products to conduct scans. These have helped in detecting and correcting vulnerabilities before the platform ships. These scans are conducted regularly and are designed to detect any regressions.
The product assemblies are scanned for vulnerabilities using static code analysis. The main tool that is currently used for static code analysis is from Microsoft, and is called CAT.NET. This tool is executed regularly against the latest code in development and reports any potential vulnerability. The report is then manually analyzed and potential vulnerabilities verified. If any vulnerability is detected and verified to exist, then it is ticketed and corrected.
Every week an internal security assessment is performed on the Telligent Evolution platform. The assessment is performed by using vulnerability scanning and static code analysis tools as well as manual reviews of the latest code changes. Any vulnerability that is discovered is ticketed and corrected.
During a weekly security assessment, the entire code base is examined using static code analysis to identify vulnerabilities. The details of the tools that are used are explained in greater detail in the Vulnerability Scanning section. The analysis is an excellent way to find new vulnerabilities introduced in recent code commits.
The manual review of the Telligent Evolution platform code follows the OWASP Testing Guide v3 and the internal secure coding guidelines. The security threats that are tested for follow a combination of the OWASP threat classification and WASC Threat Classification v2. Additionally during this process, the code is also reviewed for any logic bugs. Below is a sample of some of the threats detected during the security assessment and how they map to OWASP and WASC threats. The table below also demonstrates how vulnerabilities are ticketed and reported.
Configuration Management Testing
URL Redirector Abuse
Abuse of Functionality
Insufficient Password Recovery
Insufficient Session Expiration
Cookies are HTTP Only
Cross Site Request Forgery
Data Validation Testing
Reflected Cross Site Scripting
Stored Cross Site Scripting
DOM based Cross Site Scripting
Cross Site Flashing
Mail Command Injection
HTTP Splitting / Smuggling
Denial of Service
Locking out accounts
Any vulnerability that is discovered at any stage of development is ticketed and fixed. Vulnerabilities are rarely discovered in the wild; most of the time, they are discovered through an internal security assessment and fixed prior to release. Below is a list of some of the threats that are mitigated and some of the steps that are taken to eliminate their occurrence.
User-generated content has any included markup filtered through a white list of allowable markup. Certain items, like in-line styles that position content in a fixed manner, are not included. Additionally, IFrames are disabled to prevent loading external pages in-line. Several other unsafe attributes and elements are removed from user content prior to saving it to the database. This reduces the ability for an attacker to generate spam content or content that appears to be on behalf of the site.
The code base is actively scanned for this type of vulnerability on a regular basis. Code has been reviewed and mechanisms are in place to ensure that this type of threat is protected against. Content is sanitized and properly encoded before it is rendered to users.
The code base has mechanisms in place to ensure that form requests are from the same origin as the site and originating because of the user's action. New code is scanned for possible CSRF vulnerabilities using both static code analysis tools and vulnerability scanning tools. CSRF vulnerabilities are usually considered high priority and fixed immediately.
The code base is continuously examined looking for logic bugs that could make it easier for an attacker to perform a DoS attack. One type of DoS, ReDoS, is checked for with all new regex that is introduced into the platform.
Safe parsing techniques are employed to prevent integer overflow issues. Similarly, other types are parsed in a safe way to prevent overflow scenarios.
Before user input is passed to LDAP it is sanitized appropriately to prevent LDAP injection attacks.
Null byte injection is actively tested for and code is analyzed for logic flaws that could be exploited by null bytes. Extra sanitation methods have been added to help prevent future null byte injection attacks.
Attacks against file storage are tested for, in particular path traversal attacks. There have not been any issues discovered and measures are taken that prevent path traversal. Best practices are also documented that would mitigate a successful path traversal vulnerability being used to access sensitive Web files.
Best practices dictate that file storage should not be located in the same directory as the Web site. This helps avoid SSI attacks from including sensitive Web files like the connection strings configuration. Furthermore, files that allow SSI are not allowed to be uploaded by users.
The current code base and code that is changed are frequently scanned for SQL injection vulnerabilities. Steps are taken to sanitize potentially dangerous input, which mitigates SQL injection attacks. Furthermore, parameterized queries and stored procedures are used in order to help prevent SQL injection.
Any redirection that occurs on a site is limited to the sites origin. Additionally, any potentially dangerous redirection issues are considered serious and corrected immediately.
Steps are taken to prevent XML DoS attacks from occurring as a result of XML entity expansion. Extra protections exist on XML processing to stop these types of attacks.
Validation on the client matches the validation on the server for user input. Furthermore, input is sanitized and properly encoded to prevent vulnerabilities.
Content that is displayed to a user is processed through a permissions engine that ensures that the accessing user is authorized to view the content. Programmer comments are also not written to the markup, which reduces any source code disclosure.
Security is an important consideration given to Telligent products. While we strive to prevent opportunities for vulnerabilities and exploits, assistance from the community fortifies our efforts to develop secure products. If you identify a potential security issue, please submit the details to email@example.com. All submissions will be regarded as serious matters and given urgent attention.
All customers will be notified both via email and as a notification on this site once an issue is verified and a fix or workaround is available. Due to the sensitive nature and potential impact of any security issue, updates and fixes may not provide details.
Powered by Zimbra