[toc]
Introduction
This document is designed to give you a brief overview of some of the security-related processes that occur during the development of Telligent Community. It also describes the threats that are tested for in Telligent Community. Lastly, it details part of the incidence response that will occur if vulnerabilities are discovered.
Microsoft Software Development Lifecycle-Agile
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.
Secure development guidelines
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 Telligent Community.
Weekly security assessments
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.
Threat modeling
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.
Vulnerability scanning
Passive vulnerability scanning
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.
Active vulnerability scanning
There are several scanners that are used to detect vulnerabilities in Telligent Community. 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.
Static code analysis
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.
Continuous security assessments
Every week an internal security assessment is performed on Telligent Community. 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.
Static code analysis
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.
Manual code review
The manual review of Telligent Community 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.
Category |
Ref. Number |
Test Name |
Ticket |
Finding |
Information Gathering |
OWASP-IG-001 |
Robots Configuration |
|
|
OWASP-IG-004 WASC-45 |
Fingerprinting |
|
|
|
OWASP-IG-006 WASC-13 |
Information Leakage |
|
|
|
Configuration Management Testing |
OWASP-CM-004 WASC-14 |
Server Misconfiguration |
|
|
OWASP-CM-007 WASC-02 |
Insufficient Authorization |
|
|
|
WASC-38 |
URL Redirector Abuse |
|
|
|
WASC-42 |
Abuse of Functionality |
|
|
|
WASC-12 |
Content Spoofing |
|
|
|
Authentication Testing |
OWASP-AT-004 WASC-11 |
Brute Force |
|
|
OWASP-AT-005 WASC-01 |
Insufficient Authentication |
|
|
|
OWASP-AT-006 WASC-49 |
Insufficient Password Recovery |
|
|
|
Session Management |
OWASP-SM-001 WASC-47 |
Insufficient Session Expiration |
|
|
OWASP-SM-002 |
Cookies are HTTP Only |
|
|
|
OWASP-SM-003 WASC-37 |
Session Fixation |
|
|
|
OWASP-SM-005 WASC-9 |
Cross Site Request Forgery |
|
|
|
Authorization Testing |
OWASP-AZ-001 WASC-33 |
Path Traversal |
|
|
OWASP-AZ-003
|
Privilege Escalation |
|
|
|
Data Validation Testing |
OWASP-DV-001 WASC-8 |
Reflected Cross Site Scripting |
|
|
OWASP-DV-002 WASC-8 |
Stored Cross Site Scripting |
|
|
|
OWASP-DV-003 WASC-8 |
DOM based Cross Site Scripting |
|
|
|
OWASP-DV-004 WASC-8 |
Cross Site Flashing |
|
|
|
OWASP-DV-005 WASC-19 |
SQL Injection |
|
|
|
OWASP-DV-006 WASC-29 |
LDAP Injection |
|
|
|
OWASP-DV-008 WASC-23 |
XML Injection |
|
|
|
OWASP-DV-009 WASC-36 |
SSI Injection |
|
|
|
OWASP-DV-010 WASC-39 |
XPath Injection |
|
|
|
OWASP-DV-011 WASC-30 |
Mail Command Injection |
|
|
|
OWASP-DV-013 WASC-31 |
OS Commanding |
|
|
|
OWASP-DV-016 WASC-25 |
HTTP Splitting / Smuggling |
|
|
|
Denial of Service |
OWASP-DS-001 WASC-10 |
SQL Wildcard |
|
|
OWASP-DS-002 WASC-10 |
Locking out accounts |
|
|
|
Category |
Ref. Number |
Test Name |
Ticket |
Finding |
Eliminated risks
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.
Content spoofing
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.
Cross site scripting
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.
Cross site request forgery
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.
Denial of service (DoS)
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.
Integer overflows
Safe parsing techniques are employed to prevent integer overflow issues. Similarly, other types are parsed in a safe way to prevent overflow scenarios.
LDAP injection
Before user input is passed to LDAP it is sanitized appropriately to prevent LDAP injection attacks.
Null byte injection
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.
Path traversal
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.
SSI injection
Best practices dictate that file storage should not be located in the same directory as the website. 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.
SQL injection
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.
URL redirector abuse
Any redirection that occurs on a site is limited to the site's origin. Additionally, any potentially dangerous redirection issues are considered serious and corrected immediately.
XML entity expansion
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.
Improper input handling
Validation on the client matches the validation on the server for user input. Furthermore, input is sanitized and properly encoded to prevent vulnerabilities.
Information leakage
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.
Incident response
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 telligent-security@verint.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.