Wednesday, October 22, 2008
Latest Update: Version 1.54 Build 1206 - October 11, 2008.
Build 1206 - Download Latest Cumulative Update - October 11, 2008
If the PTA Risk Assessment tool is already installed on your computer, we strongly recommend that you keep it up-to-date by downloading a free cumulative update with the latest improvements and bug fixes (4MB size; less than 1 minute download time, applicable for all previous versions of PTA).
Build 1206 introduces a revised reporting system which enables better aggregation and sorting of threat model data and analysis results. The new mechanism allows users to define simple Tags Filter queries which filter the data shown in reports according to the tags attached to the threat’s model entities.
Thanks to Andy Baron for his excellent tip on sorting report records at runtime and to Jerry Lee for his great help in defining the tags query UI.
Build 1206 is fully compatible with all existing PTA threat models and libraries versions.
If this is your first time with PTA, you are invited to visit our download area and get a full version of the PTA Professional Edition Risk Assessment tool.
Latest Support Notes :
If you encounter problems when trying to run PTA for the first time after installation:
Please have a look at section 8 in PTA Support & FAQ page which includes a few updated solutions regarding difficulties in running PTA on machines with Office 2007/2003 installed.
How do I know the current version of PTA installed on my computer?
Click the Help About menu option in PTA main menu. The About dialog displays the current PTA version and build number.
Monday, February 18, 2008
The main objective of testing is to find defects in requirements, design, documentation, and code as early as possible. The test process should be such that the software product that will be delivered to the customer is defect less. All Tests should be traceable to customer requirements.Test cases must be written for invalid and unexpected, as well as for valid and expected input conditions. A necessary part of a test case is a definition of the expected output or result. A good test case is one that has high probability of detecting an as-yet undiscovered error.Eight Basic Principles of Testing· Define the expected output or result.· Don't test your own programs.· Inspect the results of each test completely.· Include test cases for invalid or unexpected conditions.· Test the program to see if it does what it is not supposed to do as well as what it is supposed to do.· Avoid disposable test cases unless the program itself is disposable.· Do not plan tests assuming that no errors will be found.The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module.Best Testing Practices to be followed during testing· Testing and evaluation responsibility is given to every member, so as to generate team responsibility among all.· Develop Master Test Plan so that resource and responsibilities are understood and assigned as early in the project as possible.· Systematic evaluation and preliminary test design are established as a part of all system engineering and specification work.· Testing is used to verify that all project deliverables and components are complete, and to demonstrate and track true project progress.· A-risk prioritized list of test requirements and objectives (such as requirements-based, design-based, etc) are developed and maintained. · Conduct Reviews as early and as often as possible to provide developer feedback and get problems found and fixed as they occur.
Posted by expert at 12:38 AM 0 comments
Friday, February 01, 2008
Friday, January 25, 2008
Buggy and insecure software applications are the top factor in security breaches.
The majority of data breaches are caused by attackers that exploit application software vulnerabilities. Attackers are not limited to Islamic cyber-terror groups like Team Evil, that exploited a known vulnerability in the Invision Power Board Web application. Software vulnerabilities are increasingly exploited by threats from trusted insiders such as contract programmers who have access to the source control repositories of company projects.
We improve software security with software quality
Software defect reduction is a highly economical way of preventing data breaches. You may be able to save hundreds of thousands of dollars in your security budget by decisive, focused software defect reduction.
We carry out a systematic threat analysis on critical business and Internet-facing Web applications after choosing a particular business unit and application functions. You get a cost-effective risk mitigation plan that shows you where and how you should remove software defects and how best to maintain reliable software.
The process requires executive level sponsorship that will later on, need to buy into implementation of the risk mitigation plan. The team members are chosen at a preliminary planning meeting with the lead consultant and the project's sponsor. There are typically 4-8 active participants with relevant knowledge of the business and the software. The team is lead by 2-4 expert Software Associates consultants that have the domain expertise, people skills and patience to guide a chaotic process.
The threat analysis follows a 7 step process: Set scope, Identify business assets, Identify software components, Classify vulnerabilties, build a system threat model, build the risk-mitigation plan and validate findings. Since there is normally a great deal of shared information between process steps, control flows asynchronously between steps.
Companies that perform software application threat analysis receive a clear picture of where to focus their software quality and application patching efforts.
Contact us today for a free consultationUS: +1 301-841-7122Israel: +972 (0)3 610 9750Sales AT software DOT co DOT il
More professional services from Software Associates
Digital Asset Protection
Business vulnerability assessment
Risk control optimization
Featured research articles
Software security assessment of production systems
The 7 step process for software threat analysis
Practical threat analysis in software development
10 questions your CEO should be able to answer
Wednesday, January 23, 2008
The current release of CMMI is Version 1.2. There are two version 1.2 models now available:
CMMI for Development (CMMI-DEV), Version 1.2 was released in August 2006. It addresses product and service development processes.
CMMI for Acquisition (CMMI-ACQ), Version 1.2 was released in November 2007. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
Regardless of which model you choose, CMMI best practices should be adapted to each individual organization according to its business objectives. Organizations cannot be CMMI "certified." Instead, an organization is appraised (e.g., using an appraisal method like SCAMPI) and is awarded a 1-5 level rating. The rating results of such an appraisal can be published if released by the appraised organization.
1 Process Areas
5 CMMI Concepts
8 See also
9 External links