Restricting
Authenticating
Tracking
User Access?
Time Is Not
On Our Side!
Page 1 of 3
12100 Sunrise Valley Dr. Suite 290-1 Reston, VA 20191
Security code analysis is not a matter of choosing between static or
dynamic. Both are extremely critical and have unique sets of fea-
tures.
Why is it critical?
Static code analysis is a frequently neglected aspect of cyber security, often
made more critical if your entity engages in off-shore development where
cyber-crime is rampant (for example, in countries in the former Soviet
Block, or in Asia). Regardless of where the code originated, you can be
liable for problems caused by source code that your corporation never
inspected. The code is yours whether you like it or not, and whether you
saw it or not.
War Stories
Two recent, real-world examples of Static Code Security Analysis:
1. A client specified encryption for a mobile application platform. A
code inspection revealed that data was not being encrypted, but was instead
being obfuscated in a non-secure manner. Not only did the code fail to
meet client specifications, but this issue could have easily led to major
vulnerabilities and potential non-compliance.
2. A corporation customized a portion of a web application to meet
their requirements. An analysis of the code for this custom application
revealed a failure to limit-check for a form field. This issue presented a
buffer overflow vulnerability, handing control of the web server and a
myriad of other malicious opportunities, such as cross-site scripting, to any
potential cyber-criminal.
What is it?
To use an automobile analogy, when diagnosing a fault with your car
engine, do you open the hood and poke around in the engine compartment
with the engine running? Sure, you look at the entire running system and
perform tests, listen for anomalies, and so forth. However, to better inspect
the components, you also turn the engine off and examine them.
Omitting Static Code Security Analysis
Can Cost You More than You Think!
Regardless of where
the code originated,
YOU can be liable
for problems caused
by sourcecode....
COPYRIGHT © 2015 VIMRO, LLC. ALL RIGHTS RESERVED. ALL REFERENCED COMPANY NAMES AND LOGOS ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS
Similarly, there are two types of secure code analysis: static and dynamic, each
with its unique capabilities. To continue with the car analogy, static code analysis
is performed with the engine off; and dynamic code analysis, with the engine on.
Dynamic code analysis locates runtime code vulnerabilities within the interactions between back
end and supporting components. These vulnerabilities can only be observed while code is actually
executing. Key examples are SQL injection and Cross Site Scripting attacks, which often
either lead to compromise of application data, or alter the data sent and received by the appli-
cation.
Static code analysis identifies more obscure code vulnerabilities, such as improper pointer type
conversions and buffer overrun conditions. Often these vulnerabilities either expose the course of
program execution to be altered once the code is running, or allow the underlying operating
system to be compromised. Static code inspection also reveals any accessible artifacts left behind
after an application completes execution or fails abnormally; these artifacts take the form of
plain text credentials to back end services, or of other sensitive application information left in
volatile memory.
While each type of secure code analysis has its relative strengths and weaknesses,
both are critical, and the end goal of these efforts is to isolate areas in applica-
tions where vulnerabilities can be exploited. As a standalone technique, it is
difficult or even impossible to examine all the possible permutations of applica-
tion execution paths limiting the value of dynamic code inspection.
(800) 272 0019
Ashburn, VA | Baltimore, MD | Boston, MA | Glendale, CA | Las Vegas, NV | Reston, VA | San Diego, CA | Tampa, FL
Authored by VIMRO’s Cybersecurity Leaders
Code Security Analysis
Page 2 of 3
T
....the end goal of
these efforts is to
isolate areas in
applications where
vulnerabilities can be
exploited.
COPYRIGHT © 2015 VIMRO, LLC. ALL RIGHTS RESERVED. ALL REFERENCED COMPANY NAMES AND LOGOS ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS
VIMRO recognizes that secure code analysis must be tightly integrated into
the application development process. Often, code in the Systems Develop-
ment Life Cycle (SDLC) process is unit-based and does not constitute a
complete application. In these cases, the recommended path is to first per-
form static code inspection on code modules, and then, once the code mod-
ules have been combined into an executable application, to perform aggre-
gate dynamic code inspection. And, once an application is assembled, consid-
er the destroying, or “freeing, memory structures left behind after execution
is completed. Your consideration should also take into account instances
where the application terminates abnormally: generally, any “try – exception”
type error handling should free as many memory structures as possible and
close any open files.
VIMRO has many more considerations in place for applications. Con-
tact us now for a preliminary review of your challenges and possible solu-
tions. services@vimro.com
(800) 272 0019
(800) 272 0019
Ashburn, VA | Baltimore, MD | Boston, MA | Glendale, CA | Las Vegas, NV | Reston, VA | San Diego, CA | Tampa, FL
Authored by VIMRO’s Cybersecurity Leaders
Code Security Analysis
Page 3 of 3
T
....first perform static
code inspection on
code modules....
then once the code
modules have been
combined into an
executable app.,
perform aggregate
dynamic code
inspection.

CODE INSPECTION VIMRO 2015 MHF

  • 1.
    Restricting Authenticating Tracking User Access? Time IsNot On Our Side! Page 1 of 3 12100 Sunrise Valley Dr. Suite 290-1 Reston, VA 20191 Security code analysis is not a matter of choosing between static or dynamic. Both are extremely critical and have unique sets of fea- tures. Why is it critical? Static code analysis is a frequently neglected aspect of cyber security, often made more critical if your entity engages in off-shore development where cyber-crime is rampant (for example, in countries in the former Soviet Block, or in Asia). Regardless of where the code originated, you can be liable for problems caused by source code that your corporation never inspected. The code is yours whether you like it or not, and whether you saw it or not. War Stories Two recent, real-world examples of Static Code Security Analysis: 1. A client specified encryption for a mobile application platform. A code inspection revealed that data was not being encrypted, but was instead being obfuscated in a non-secure manner. Not only did the code fail to meet client specifications, but this issue could have easily led to major vulnerabilities and potential non-compliance. 2. A corporation customized a portion of a web application to meet their requirements. An analysis of the code for this custom application revealed a failure to limit-check for a form field. This issue presented a buffer overflow vulnerability, handing control of the web server and a myriad of other malicious opportunities, such as cross-site scripting, to any potential cyber-criminal. What is it? To use an automobile analogy, when diagnosing a fault with your car engine, do you open the hood and poke around in the engine compartment with the engine running? Sure, you look at the entire running system and perform tests, listen for anomalies, and so forth. However, to better inspect the components, you also turn the engine off and examine them. Omitting Static Code Security Analysis Can Cost You More than You Think! Regardless of where the code originated, YOU can be liable for problems caused by sourcecode....
  • 2.
    COPYRIGHT © 2015VIMRO, LLC. ALL RIGHTS RESERVED. ALL REFERENCED COMPANY NAMES AND LOGOS ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS Similarly, there are two types of secure code analysis: static and dynamic, each with its unique capabilities. To continue with the car analogy, static code analysis is performed with the engine off; and dynamic code analysis, with the engine on. Dynamic code analysis locates runtime code vulnerabilities within the interactions between back end and supporting components. These vulnerabilities can only be observed while code is actually executing. Key examples are SQL injection and Cross Site Scripting attacks, which often either lead to compromise of application data, or alter the data sent and received by the appli- cation. Static code analysis identifies more obscure code vulnerabilities, such as improper pointer type conversions and buffer overrun conditions. Often these vulnerabilities either expose the course of program execution to be altered once the code is running, or allow the underlying operating system to be compromised. Static code inspection also reveals any accessible artifacts left behind after an application completes execution or fails abnormally; these artifacts take the form of plain text credentials to back end services, or of other sensitive application information left in volatile memory. While each type of secure code analysis has its relative strengths and weaknesses, both are critical, and the end goal of these efforts is to isolate areas in applica- tions where vulnerabilities can be exploited. As a standalone technique, it is difficult or even impossible to examine all the possible permutations of applica- tion execution paths limiting the value of dynamic code inspection. (800) 272 0019 Ashburn, VA | Baltimore, MD | Boston, MA | Glendale, CA | Las Vegas, NV | Reston, VA | San Diego, CA | Tampa, FL Authored by VIMRO’s Cybersecurity Leaders Code Security Analysis Page 2 of 3 T ....the end goal of these efforts is to isolate areas in applications where vulnerabilities can be exploited.
  • 3.
    COPYRIGHT © 2015VIMRO, LLC. ALL RIGHTS RESERVED. ALL REFERENCED COMPANY NAMES AND LOGOS ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS VIMRO recognizes that secure code analysis must be tightly integrated into the application development process. Often, code in the Systems Develop- ment Life Cycle (SDLC) process is unit-based and does not constitute a complete application. In these cases, the recommended path is to first per- form static code inspection on code modules, and then, once the code mod- ules have been combined into an executable application, to perform aggre- gate dynamic code inspection. And, once an application is assembled, consid- er the destroying, or “freeing, memory structures left behind after execution is completed. Your consideration should also take into account instances where the application terminates abnormally: generally, any “try – exception” type error handling should free as many memory structures as possible and close any open files. VIMRO has many more considerations in place for applications. Con- tact us now for a preliminary review of your challenges and possible solu- tions. services@vimro.com (800) 272 0019 (800) 272 0019 Ashburn, VA | Baltimore, MD | Boston, MA | Glendale, CA | Las Vegas, NV | Reston, VA | San Diego, CA | Tampa, FL Authored by VIMRO’s Cybersecurity Leaders Code Security Analysis Page 3 of 3 T ....first perform static code inspection on code modules.... then once the code modules have been combined into an executable app., perform aggregate dynamic code inspection.