Download PDF - Codenomicon

More documents

Recommendations

Info

CODENOMICON WHITEPAPER - Proactive Cyber Security: Stay Ahead of Advanced Persistent Threats (APTs) 11 Fuzzing Best Practices Fuzzing can be used to test all software and software components with hardware, so you can use it to test all types applications, services and network equipment like routers, switches and servers, and also security software like antivirus and firewalls [6]. The cost of not fuzzing can be high. It can be costly, if an important network element is offline or services unavailable, never mind the consequences of an advanced cyber attack. As an acceptance condition Many vendors are in a hurry to push software onto the market, and often times it is the user who ends up doing the testing [12]. Actually, software products have the highest rate of defects of product sold today [12]. By insisting on using fuzzing as an acceptance condition, you can make vendors claim responsibility over the quality and security of their products [6]. A prominent US ISP already uses fuzzing as entry criteria for its network suppliers [7]. The <strong>Codenomicon</strong> Defensics test suites automatically collect all important information on found vulnerabilities into a Remediation Package, which you can send to third parties for automated reproduction [23]. During SDL Large software houses already include fuzzing as a part of their secure development lifecycles: Cisco’s CSDL, Microsoft’s SDLC and the Adobe Product lifecycles are good examples of this. Giants like IBM and Google also promote fuzzing [12]. The Microsoft secure development lifecycle (SDL) model endorses the use of fuzzing in the verification phase [24]. However, fuzzing can be used throughout the development process from the moment the first software components are ready to even after the release [24]. The earlier the vulnerabilities are found, the easier and cheaper it is to fix them [1]. Indeed, by building security into your software you can avoid costly, critical and embarrassing software blunders. During production In addition to fuzzing before development, the production environment should also be tested, because testing elements in isolation does not always reveal the same issues as testing a live environment [6]. However, this may disturb the tested system, because it is essentially simulating an attack against it [24]. Thus, it should only be done after extensive testing and in the presence of support personnel [24]. Augmenting parameter security defenses During the lag time between threat discovery and signature deployment, the IDS (intrusion detection system) is unable to identify the threat [23]. Help your defenses block attacks exploiting zero-day vulnerabilities by using the extensive documentation that Defensics provides [23]. The test cases triggering vulnerabilities in your system are described clearly making it easy to write your own IDS rules [23]. The rules can be based on vulnerabilities found by running predefined Defensics tests, or testing around known vulnerabilities downloaded from third party vulnerability feeds [23]. You can also use Defensics to generate variations of the original attack and to test how well IDS/IPS systems and firewalls can detect and block both the original attack and variations of it [23].
CODENOMICON WHITEPAPER - Proactive Cyber Security: Stay Ahead of Advanced Persistent Threats (APTs) 12 Abuse Situation Awareness Best Practices To respond to cyber attacks in a timely and effective manner, organizations need to adopt systematic incident handling processes. To develop such processes is the ability to share real abuse situation information. The key to designing an effective situation awareness system is understanding that real situation awareness only exists in the mind of the human operators [14]. Thus, tons of data will not help unless it successfully transmitted, absorbed and assimilated in a timely manner by the operator [14]. Here are some best practices for abuse situation awareness. Automated Data Collection External abuse feeds are an under-used resource, and it is easy to understand why: There can be billions of abuse notifications daily, each of them different in terms of timing, format, transport and content [3]. Security personnel must sift through emails, website postings or other communications. In most organizations, these tasks are performed manually by skilled analysts. It makes a lot of sense automate basic tasks like collecting and processing abuse information, and free up the analysts’ time to do the actual analysis [3]. Automated Analysis Expertise plays a major role in situation awareness [14]. An experienced operator will be able to spot similarities between events, even if the events are not exactly alike [14]. For novices this task is much harder [14]. Thus, a good situation awareness system should help the operators draw parallels between events [14]. In AbuseSA, incidents are stored into a knowledge database for users with access rights to share. This information can be used to automatically augment abuse feeds’ information in real-time. For example, if a certain IP address has been identified as a drop-time, then traffic to this address will immediately be flagged as high risk. Actionable Reporting Abuse feed transports and formats vary considerably. Reporting standards, on the other hand, can be strict [17]. The AbuseSA sanitizes and normalizes all the information, sending reports to stakeholders at preferred times, in preferred formats. Actionable reporting enables stakeholders to take swift action. Organizations often waste time handling notifications that contain inaccurate, false or old information, or do not contain vital information, like IP-addresses. The AbuseSA removes all this information only reporting actionable abuse information.
Page 1 and 2: Codenomicon whitepaper: Proactive C
Page 3 and 4: CODENOMICON WHITEPAPER - Proactive
Page 9: CODENOMICON WHITEPAPER - Proactive

Download PDF - Codenomicon

Create successful ePaper yourself

Delete template?

Save as template?