280 likes | 433 Views
Security Risks beyond the Network: Developing Secure Solutions. Jeff Zado jzado@microsoft.com Sr. Product Manager Development Tools Microsoft Canada. Abstract.
E N D
Security Risks beyond the Network: Developing Secure Solutions Jeff Zado jzado@microsoft.com Sr. Product Manager Development Tools Microsoft Canada
Abstract Ensuring that your organization’s applications are secure is no longer just about firewalls, networks and simple authentication. Security is a big challenge for organizations and the price of failure could mean disastrous results for companies and shareholders. But I am sure that you all know this, as you are security experts. However, developing secure software is a relatively new discipline that organizations are adopting and integrating throughout the software development lifecycle. In this talk we will look at common application security issues, how companies can identify them earlier in the development lifecycle and how Microsoft solutions can be leveraged to assist you and our organizations.
“We cannot adopt the way of living that was satisfactory a hundred years ago. The world in which we live has changed, and we must change with it. “ Felix Adler
State of the Industry “Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” Gartner “The battle between hackers and security professionals has moved from the network layer to the Web applications themselves“ Network World “64 percent of developers are not confident in their ability to write secure applications” Microsoft Developer Research “Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money” Counterpane Internet Security
Security BreachesAffecting Businesses and Consumers Britain warns ofmajor e-mail attack 40M credit cards hacked Hackers seen aiming at government, corporate networks Breach at third party payment processor affects 22 million Visa cards and 14 million MasterCards.June 20, 2005: 3:18 PM EDT By Jeanne Sahadi, CNN/Money senior writer The Associated Press Updated: 1:42 p.m. ET June 16, 2005 In 2004, 78% of enterprises hit by viruses, 49% had laptops stolen, 37% reported unauthorized access to information --2004 CSI and FBI Computer Crime and Security Survey
The FTC reports 1,000 cases a day of ID theft A recent FBI operation put an end to a scheme in which nearly 150,000 victims lost more than $215 million The number of phishing e-mail messages intercepted by a prominent web security company grew 300% since June 2004 Over 80% of the top 100 financial institutions have reported external attacks on their IT systems in the past year
June 23, 2006 Another Government Security Breach "There ought to be an assumption that data is encrypted when it is at rest or in transit," Kurtz said. "With encryption, a stolen laptop is simply a stolen laptop."
Elements that Drive Change People: Providing guidance on secure application development Process: Security cannot be an afterthought Tools: Providing the most innovative tools
People: Education as a Driver Patterns & Practices Dedicated team focused on security guidance MSDN and TechNet Sharing whitepapers and “how tos” Education Train every Developer and IT Professional on security
Process: Security Development Lifecycle (SDL) A PROCESS by which Microsoft develops software and defines security requirements and milestones • Reduce the number of security errors • Reduce the severity of any security errors not found • Reduce the attack surface
Accountability and Incentives Microsoft Developer Research: Almost 40 percent of developers say that their companies do not think it is “very important” to write secure applications CXOs and management say it is very important Current incentives on performance and ship dates Must be driven top-down
Tools: Utilizing Innovation Tools facilitate creating secure applications Secure by Default Create non-admin apps Static Analysis Scan your code for security vulnerabilities Secure Software Development Lifecycle Process Seamless create applications for a custom zone Nurturing the Partner Ecosystem
Canadian Events and Expertise MSDN, Technet and Security Events and web resources Threat Modeling: http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/video/
Consequences of Inappropriate Input Handling Lead to a realization of various attack patterns Cross-Site Scripting (XSS) One-Click Attacks SQL Injection Canonicalization issues Buffer overflow or arithmetic errors (Memory Management issues) Denial of Service
What is Cross-Site Scripting? A technique that allows attackers to: Appear to rewrite the text of your web site Abuse the user’s trust in your website to… Steal Web session information and cookies Hijack client sessions Potentially access the client computer
Defending Against Cross-Site Scripting Attacks Do not: Trust user input Echo client-supplied data without encoding Store secret information in cookies Do: Take advantage of ASP.NET’s RequestValidation Take advantage of ASP.NET’s ViewStateUserKey Consider IOSec for data encoding (http://toolbox/details/details.aspx?ToolID=22241) Use the HttpOnly cookie option Use the <frame> security attribute
What is One-Click Attack? Site offers persistent sign-in option (cookies) Victim user navigates to (or opens) an HTML page – perhaps a “once in a lifetime offer” One or more actions are carried out using the trust of the victim user which is completely unsuspecting to that user
Defending Against One-Click Attack Browser’s cross-frame security limits this to a “write-only” attack Concept for defense: require a data element in the request which the attacker can’t supply (Overkill) Re-authenticate the user Can ask for confirmation Check Referrer field document.location or window.open() don’t post Referrer
Defending Against One-Click Attack (cont.) Classic ASP Generate a unique session ID once user authenticates, encrypt it and bind it to each response sent to user In .Net 1.1 use ViewStateUserKey Value assigned to it must be unique to the current user This value is used as a factor in the ViewState MAC override protected void OnInit(EventArgs e) { // ... ViewStateUserKey=User.Identity.Name; // ... }
What is SQL Injection? SQL injection is: The process supplying carefully crafted input to alter (or create) SQL statements Can be used by malicious users to compromise confidentiality, integrity or availability of your application: Probe databases Bypass authorization Execute multiple SQL statements Call built-in stored procedures
Defending Against SQL Injection Abandon Dynamic SQL Use stored procedures or SQL parameterized queries to access data Can have SQL Injection in stored procedures Sanitize all input Consider all input harmful until proven otherwise – test for valid data and reject everything else Run with least privilege Never execute as “sa” Restrict access to built-in stored procedures Do not display ODBC errors
What are Memory Management Issues Buffer Overrun Exists primarily in unmanaged (C/C++) code Can lead to a host-level exploits – keep your host patched and up-to-date Arithmetic Errors
What are Arithmetic Errors Occur when the limitations of a variable are exceeded E.g., Assign the value 300 to a byte Lead to serious runtime issues Are often overlooked and underestimated Include: Overflow – value too large for data type Underflow – value too small for data type
Logging Application Security is more then setting up perimeter defense Keep a log trail of authentication attempts Both successful and failed Keep a log trail of all accesses to assets Log as close to an asset as possible SQL Server Stored Procedure Sometimes… a log trail is the only mitigation Identify “who, what, where & when”…
What you Log “Fire and Forget” – Asynchronous logging MSMQ Don’t write sensitive information in logs Passwords Identify the (“who, what, where & when”): Identity Action Component/Service/Object/Method Timestamp
Audit Logs identify the “who, what, where & when” Audit the logs to determine “why” Setup a process whereby logs are audited Monitor & Response Process Can be automated to some extent Log files are an asset!
A (Quick) Summary Use existing technologies that meet your needs… But implement appropriately! Think cynical – don’t trust outside sources Application users External dependencies