17. Assumption Costs vs. Failure Costs No countermeasures, cost of failure (e.g. data breach is high) Cost is low but CBRatio >1 CBRatio <1 but room for improvement Optimal Spending, around 37% (Gordon and Loeb)
18.
19. Data Losses As Web Breaches (datalossdb.org) SOURCE: Open Security Foundation Data Loss Statistics
Because of the current economic recession, security managers have to deal with shrinking budgets and limited resources dedicated to application security and often asked to present the “business cases” for application security as well as software security initiatives. Gartner Survey Shows Security Software and Services Budgets to Increase 4 Per Cent in 2010 Analysts Discuss Key Security Issues During Gartner Information Security Summit, 21-22 September in London Egham, UK, September 8, 2009 — Security software and services spending will outpace other IT spending areas in 2010, according to a new survey by Gartner, Inc. Security software budgets are expected to grow by approximately 4 per cent in 2010, outpacing all other areas of infrastructure software. Security services budgets are projected to grow almost 3 per cent, significantly outperforming other service areas. In April and May of 2009, Gartner surveyed more than 1,000 IT professionals with budget responsibility worldwide to determine their budget-planning expectations for 2010. “ In the current highly uncertain economic environment, with overall IT budgets shrinking, even the modest spending increases indicated by the survey show that security spending accounts for a higher percentage of the IT budget,” said Adam Hils, principal research analyst at Gartner. “Security decision makers should work to allocate limited budgets based on enterprise-specific security needs and risk assessments.” Specific areas of projected security-related software spending growth in 2010 includes security information and event management (SIEM), e-mail security, URL filtering, and user provisioning. The continued, comparatively strong emphasis on security extends beyond software. The survey showed that security services spending will also outpace spending in other services areas, with budgets expected to grow 2.74 per cent in 2010. This anticipated increase is being driven in part by a growing movement towards managed security services, cloud-based e-mail/web security solutions, and third-party compliance-related consulting and vulnerability audits and scans. “ When evaluating and planning 2010 security budgets, organisations should work to achieve a realistic view of current spending and recognise that it may be impossible to capture all security-related spending because of organisationally diffused security budgets,” said Ruggero Contu, principal research analyst at Gartner. “Businesses should also recognise that new threats or vulnerabilities may require security spending that exceeds the amounts allocated, and should consider setting aside up to 15 per cent of the IT security budget to address the potential risks and impact of such unforeseen issues.” Additional detail is available in the Gartner report “ Security Software and Services Spending Will Outpace Other IT Spending Areas in 2010 .&quot; The report is available on Gartner’s website at http://www.gartner.com/DisplayDocument?ref=g_search&id=1141513&subref=simplesearch . Key issues facing the security industry will be discussed during the Gartner Information Security Summit, taking place 21 -22 September, at the Royal Lancaster hotel in London. The Summit hits the critical spot between strategic planning and tactical advice. Gartner analysts, industry experts and IT security practitioners will deliver unbiased, realistic analysis of the current state of information security, as well as an independent vision of how things will evolve over the long term. For complete event details, please visit the Gartner IT Security Summit website at http://www.gartner.com/it/page.jsp?id=787512 . Members of the media can register by contacting Holly Stevens at [email_address] .
# 1 per creare il caso e’ creare awareness come ad esempio le conference OWASP di questo tipo. E’ di importanza critica definere il problema per esempio spiegare ad executive management cosa si intende per secure software security engineering e come sia diversdo da application security e perimiter security for example. #2 preparazione per le FAQs come e perche e dove devo spendere il mio budget in software security?
Maybe compliance is #1, analysts opinions and surverys #2 , incidents #3 and cost savings #4 dal punto di vista della mia esperienza
Anche tenendo conto che I piu grandi incidenti di perdita di dati sensibili nella storia degli USA sono dovuti a problem di application security Heartland Payment Systems (HPY) data breach: 130 Credit Card Accounts Exploited SQL Injection vulnerabilities to install malware (Hannaford 9/07, Company A & B on 1/08) Used “wardriving” and installed sniffers Acted ad member of a Cybercrime gang Profited from the sale of ACC#, PINs to fake credit cards and commit ATM fraud Engaged in money laundering
Come mostrato in questo caso… In same cases the cyber attack vectors are reported step by step Use &quot;xp_cmdshell“ to download hacker tools to the compromised MSSQL server. Obtain valid Windows credentials by using fgdump Install network &quot;sniffers&quot; to identify card data and systems involved in processing credit card transactions. Install backdoors that &quot;beacon&quot; periodically to their command and control servers Target databases, Hardware Security Modules (HSMs), and processing applications in an effort to obtain credit card data or brute-force ATM PINs. Use WinRAR to compress the information they pilfer from the compromised networks.
Dal punto di vista dei costi, quantificazione di quanto cost gestire I dfetti del software e’ essenziale per il business cases
L’opinione degli analisti e’ che la maggioranza delle vulnerabilita’ e degli incidenti succede a livello delle applicazioni, in realta dipende dal tipo di incidenti. Dal punto di vista dei cost studi dimostrano che c’e significativamente una riduzione dei cost ed un ROI nel risolvere le issues early in the SDLC da un fattore 100X requirements vs. field test ad un fattore 10 X fra coding e test
I modelli di maturity permetttono di usare un metodo standard per ottenere una scorecard o pagella della maturita’ dei processi e delle discipline e a che livello siano riaggiunte. La metrica provvede un livello fo visiabilita’ reale e una misura delle cause, trends e bisogni
A parte la maturity un buon caso da usare e’ la metrica Defect management metrics Where the issue is found? (e.g. requirements, design, code, application) When has been fixed? (e.g. found in coding fixed before testing) How has been fixed (e.g. design change, coding, configuration) Vulnerability management metrics Which type of vulnerabilities are found the most during design review, code analysis, pen tests? Which security vulnerabilities we having trouble fixing?
E per finire I business cases debbono trovare supporto da punto di vista degli sponsors e di chi usa software security secondo diversi obbiettivi
Dal circa un anno o due abbiamo la fortuna grazie a Pravir Chandra e Gary McGraw due modelli per la software security maturity. I modelli si basano su survey di casi reali empirici do come varie organizzazioni implementano software security initiatives (35 prese in esame nel caso di BSIMM e 9 ditte di diversi settori Google, MS, Adobe e telco come qualcomm e anche DTCC , Well Fargo banks etc) I modelli sono organizzati per domini BSMIMM, business functions nel caso di SAMM in tutto molto simili anche in numero 12. I livelli di maturity sono da 1 a 3 e varie attivita per obbiettivi e livelli
Un esempio di come siano utili a parte la pagella ci danno la mappa degli obbitettivi e delle attivita da raggiungere.
Un fatto importante della maturity e’ la learning curve, lo sviluppo non e’ lineare ma accelerato dall’ apprendimento e in alcune fasi e’ piu difficile di altre come il passaggio dal livello 3 a 4 (defined a managed) questo ha importanza sul planning.
CBA costi vs benefici il beneficio ne deve valere la pena come si dice…. La formula e’ semplice ed un fattore < 1 significa I benefici sono maggiori dei costi quindi se i nebefici sono I risparmi in costi per il defect management e incidenti vs I costi per processi, people, technology.tools ed il fattore e’ <1 si puo dire che ne valga la candeal Il problema pero non e’ semplice da evalutate questi costi
Alcuni exempi di costi di assunzione del software sicuro includono il costi per lo svulippo training e implementazione mentre I costi di incidenti includono I costi di sviuppo delle patches, pen testing e I costi degli exploits/incidenti che sono I piu difficili da quantificare
Se per esempio prendiamo in considerazione il cost delle contromisure vs il costo dei danni dovuti ad un exploit di una vulnerabilita come anche I costi per le patches etc vediamo che man mano che le spese per la rimediazione dei danni aumentano I costi dovute alle perdite diminuiscono. Un esempio di come questi dati possano essere usati per esempio e che se le mei perdite grossolane dovure a frodi via banking on line channel sono 3 millioni di euro un millione di euro in spese in programmi si software security e’ giustificabile. Most organization's directors of technology and security try to sell technologies and new initiatives to high management with the sales pitch of getting the most &quot;Bang For The Buck&quot; BFTB. But the BFTB business case need to answer the basic question: if I spend that much on a security technology or process what is the benefit for security ? In technical terms this means doing a Cost vs Benefit Analysis (CBA). CBA can be used in security to correlate the total cost of security to increased information or software security assurance. Dan Geer covers well this analysis as related to data security in his book &quot; Economics and Strategies of Data Security &quot;. By analogy, in the case of software security, &quot;Bang For The Buck&quot; decision spending need to take into account the total security costs that is all failure costs such as the total cost of failing as business impact as well the total cost of finding, fixing, testing and deploying the security defect. Only then, the total cost of software security (the BUCK) can be compared against the BANG that is the increased level of software security assurance. The general law for bang for the buck is that you are getting the most bang for the buck when your total costs (cost of failure/data loss/fraud + cost of security/countermeasure) reaches a minimum. As failure costs decrease exponentially, the &quot;anticipation costs&quot; that you take proactively by spending in software security initiatives will increase. From risk management perspective this means that the total software security costs decrease up to a minimum to raise again as you keep spending on security measures. You will reach an optimal cost vs. benefit where more spending in anticipation cost (e.g. countermeasures) will not provide the most benefit (e.g. spending more in countermeasures then the value of the assets that the countermeasure is supposed to protect) This optimal spending for anticipation costs (proactive countermeasures) is about 40% of your failure costs (to be exact 37% according to Gordon and Loeb research: The Economics of Information Security Investment ). According to the empirical law of the most bang for the buck applied to software failure costs vs. assumption costs it is therefore fair to assume that you get the most of security by spending 37% of what your software failure costs are. Assume for example software security failures costs are $ 10 ML it would be reasonable for an organization to spend as much as $ 3.7 ML in acquiring software security tools and technology, develop new software security process as well as in new software security training activities.
Per un business case piu significativo e’ quantificare le perdite come ONERI per ogni perdita di dati sensibili
E’ possibile correlare tali perdite a dati statistici sugli attachi
E sulle vulnerabilita.
Usando questi dati e’ possibile stimare per esempio il costo in termini di impatto di una perdita di dati sensibilie (carte di credito) via SQL injection A similar math can be factored using Van Geer data of 4.5% of data loss probability (FTC 2003 data) x 655 $/person cost Can we correlate this losses somehow, the cost for loss with the fact that among all breaches 13 % are from wbe and 19% use SQL injection attack vectors you can come out with 0.025 that is 2.5 % as the probability that an identify theft will occurr through the web channel because of a SQL injection attack. The cost is the cost per incident x record loss for internal (pokemon is 200 $) or you can just factor the cost per re-issance of the card This multipled for the cost per incident/records you can came out with 241 ML for 14 million records for 130 ML is 2.5 BILLION According to the case in NJ SQL injection is considered cause of Hannaford http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/2008-2009%20US%20Cost%20of%20Data%20Breach%20Report%20Final.pdf http://www.securecomputing.net.au/Tools/Print.aspx?CIID=103302 Assume that according that 2003 FTC data the potential loss per identity theft incident is $ 655 per incident. Assume you are serving via your web site a population of 4 million customers, the potential loss of losing your customer data such as credit card accounts for example would be of $ 2,6 Billion and with probability of identity theft occurrence of 4.6 % (also FTC data) the projected loss for your company could be $ 120 ML for which 14% or $ 16 ML would be the cost of data losses via the web channel alone. Assume that according that 2003 FTC data the potential loss per identity theft incident is $ 655 per incident. Assume you are serving via your web site a population of 4 million customers, the potential loss of losing your customer data such as credit card accounts for example would be of $ 2,6 Billion and with probability of identity theft occurrence of 4.6 % (also FTC data) the projected loss for your company could be $ 120 ML for which 14% or $ 16 ML would be the cost of data losses via the web channel alone. With these assumptions based upon publicly disclosed data losses, a security program (that include both information and application security) that cost as much as $ 16 ML would be justified for a company with a customer base of 4 million on-line customers for example.
Come numeri siamo vicini…. http://findarticles.com/p/articles/mi_m0EIN/is_2007_August_14/ai_n27342542/
Un fattore che non si stima sono le perdite indirette intangibili per esempio sulle azioni in conseguenza alla pubblicazione di un incidente si tenga presente che nel caso di HPY l’exploit citiato nei procdeeednigns rigrairda SQL inection che e’ diretta consegienza di unsecure software
Un altra metodologia consiste nel valutare le perdite annue come fattore di esposizione alle perdite all;occorenza dell’ evento e dell’impatto dell evento (SLE)
Nel caso in esame e’ possibile stimare SLE e ALE per SQL injection tenendo conto della probabilita stimata 2.5 % di un evento per un sito che serve 3 millioni di utenti A quantitative risk assessment can also be used to determine the extent on which a software security initiative can reduce risk from potential losses. The correlation has to take into account the probability of the event and the loss that the event can cause. This is difficult to quantify in general for software security issues since assumes a cause-effect between vulnerability exploit and financial impact. Nevertheless it can be used for rough estimates. Assume a web application that delivers banking services for example and that the loss caused by an event such as denial of service impact on-line transactions for 3 million customers with an average of $ 20 per transaction: the loss per single DOS event (SLE) is $ 60 ML. Assume that the probability that a new SQL injection vulnerability would cause a denial of service is 30% (Annualized Rate of Occurrence) then the Annual Loss Expected (ALE) is $ 1.8 ML. If the cost of the new security countermeasures that will stop the security incident is less than $ 1.8 M than the organization should implement it.
Un altro fattore molto discusso a livello di esecutives e’ il ROSI che quantifica in termini di investimento in sicurezza il ritorno come risparmio. Secondo studi e’ possibile stimare il risparmio delle attivita di security engineering nelle diverse fasi per esempio
Un altra stima usando la formula di risparmi sul impatto delle perdite dopo che la soluzione di secure software e stata addottata in riferimento al cost della soluzione stessa. Un ROSI negativo non e’ giustificabile mentre uno positivo lo e’ wuanto sia giustificabile ha valore comparativo rispetto a diverse attivita.
Da punto di vista dei busienss cases un metrica in supporto e la PAGELLA BILANCIATA il cui goal e’ allineare software security ad altri obbiettivi aziendali come finanza clienti, processi e capacita interne di formazione etc. Alcuni obbiettivi di questa metrica scorecard sono mostrati qui It is used by companies to assess performance of a target process against factors that are outside the traditional time and effort costing. There are different views: the financial view tries to answer the question, to succeed financially, how should we appear to our shareholders Background The balanced scorecard is a strategic planning and management system that is used extensively in business and industry, government, and nonprofit organizations worldwide to align business activities to the vision and strategy of the organization, improve internal and external communications, and monitor organization performance against strategic goals. It was originated by Drs. Robert Kaplan (Harvard Business School) and David Norton as a performance measurement framework that added strategic non-financial performance measures to traditional financial metrics to give managers and executives a more 'balanced' view of organizational performance.
Per ogni area ci sono tre metriche: costi tecnici di software security engineering, costi di trends costi relativi al budget allocato etc
In analisi se si ha una methologia si puo’ vendere il giaccio agli eskimesi