Saturday, April 9, 2016

Fundamentals of Secure Development

Fundamentals of Secure Development

This course introduces you to the business and regulatory imperatives for secure software development. It presents models, standards, and guidelines that can help you understand security issues and improve the security posture of your applications. And, it describes how to integrate secure development practices into the software development lifecycle.

After completing this course, you will be able to:

Identify major factors in the business, regulatory, and threat landscapes that drive the demand for software security.
Identify important security models, standards, and guidelines that provide a strategic roadmap for application security.
Identify secure development practices and principles that correspond to each phase of the software development lifecycle.

What is Software Security?

Software security focuses on protecting information and resources made accessible by applications running on computer systems.

Software security is often confused with network security. Network security focuses on the protection of an organization’s IT infrastructure—the servers and related equipment that control the flow of data between networked systems.

Network security controls are typically insufficient to mitigate software security risks.

Software security attacks often occur at higher layers of operation, not visible to network security controls.

The Security Imperative

Key reasons why organizations must develop and deploy secure software include:

  • High business costs of security breaches
  • Compliance and legal implications of security breaches
  • Customer expectations of security
  • An increasing threat landscape

Compliance and Legal Implications

Federal and state regulations mandate software security and require protection of sensitive customer data.

Even if an organization is not required by local regulations to develop secure software, they might still need to do so to conduct business in other states.

It is difficult, if not impossible, to ignore software security without incurring significant fines or loss of business.

Customers Expect Secure Solutions

  • Regulatory and legislative measures and the media have increased business awareness of the need for secure software and services.
  • Failure to develop and deliver secure software and services could damage your organization’s reputation, and drive business to your competitors.

An Increasing Threat Landscape

In the past, hackers were motivated to attack systems and software to gain notoriety. Today, the number of attacks is increasing, and attackers are motivated by financial gains, political agendas, and corporate and international espionage.

Specialized hacking techniques are publicly documented and well understood by many. In addition, automated attack tools are freely available and accessible.

This translates to a higher probability of being hacked, as well as higher expected costs for recovering from cyber attacks.

Overview of Secure Development Models, Standards, and Guidelines

This module introduces you to the following secure development models, standards, and guidelines that provide a fast track to improving application security:
  • Open Web Application Security Project (OWASP) Top 10
  • Microsoft Security Development Lifecycle (SDL)
  • CWE/SANS Top 25 Most Dangerous Software Errors
  • Payment Application Data Security Standard (PA-DSS)
  • Cloud Security Alliance (CSA) Notorious Nine Report
  • Cloud Security Alliance (CSA) Top 10 Big Data Security and Privacy Challenges
  • OpenSAMM - Software Assurance Maturity Model (SAMM)
  • Building Security In Maturity Model (BSIMM)
  • Comprehensive Lightweight Application Security Process (CLASP)
  • The Common Criteria for Information Technology Security Evaluation (CC)

Important points about secure development include the following:
  • Hacker methods and attacks are constantly evolving, as are the security techniques to address them.
  • These security models, standards, and guidelines greatly improve your application security posture, but they do not make your application "hacker proof".

Security in the Software Development Lifecycle

Software development models such as Waterfall, Spiral, and Agile are generally divided into Planning, Design, Implementation, Testing, and Deployment phases. This is sometimes called the software development lifecycle (SDLC).

Secure development models are similarly divided into phases that overlay your existing software development model. Each phase describes the tasks that must be executed in each software development phase to minimize your application’s exposure risk.

Secure development models are precise in their requirements. The outputs from each phase serve as input for other phases in the model.

In comparison, standards and guidelines are less structured, providing an overview of quality baselines to achieve, vulnerabilities to be aware of, and coding patterns to follow or avoid.

Open Web Application Security Project (OWASP) Top 10

The Open Web Application Security Project, or OWASP, is an open-source, non-profit organization that provides guidance on secure Web software development, testing frameworks, and tools.

Perhaps the most well-known of their offerings is the OWASP Top 10 list, which describes the most common Web application attacks and vulnerabilities, along with example code vulnerabilities, example attacks, and guidance on mitigating the risk. OWASP Top 10 is updated every few years to help you focus on vulnerabilities that pose the most current risk.

As a developer, you benefit greatly by ensuring that your Web application is resilient to the current OWASP Top 10 vulnerabilities. However, as with any security model, standard, or guideline, following OWASP Top 10 does not necessarily eliminate all possible risks.

The Microsoft Security Development Lifecycle (SDL)

Microsoft developed the Security Development Lifecycle (SDL) to improve and sustain the overall security code quality across all of its products, services, and line-of-business applications. The SDL is a freely available security development model designed to overlay onto existing software development processes. At its core, it categorizes the secure software development process into the following phases: Training, Requirements, Design, Implementation, Verification, Release, and Response.

The Microsoft SDL yields security benefits to any software development team developing in any language on any platform. In each SDL phase, development teams must perform risk assessment and mitigation activities. For example, in the training phase, the SDL requires that each software development team member in a technical role attend at least one security training class each year. In the Implementation phase, it requires that developers use static code analysis tools, which will be discussed later in this course. The SDL requires participation of the entire software development staff, including program managers, developers, and test teams. This contrasts with other models, standards, and guidelines, which tend to focus strictly on the developer aspects of developing secure software.

Microsoft also publishes a set of tools to help software development teams implement and execute the SDL process more efficiently. Example tools include a threat-modeling tool that helps teams identify threats early in the Design phase, and a fault-injection tool to aid with security testing efforts in the Verification phase. Microsoft has also published the Simplified SDL, a lightweight framework version of the SDL available as a spreadsheet, to help organizations realize the greatest benefits of the SDL with minimal effort.

CWE/SANS Top 25 Most Dangerous Software Errors

The MITRE Common Weakness Enumeration (CWE) group and SANS Institute published a report on the top 25 most dangerous software errors. The list is intended to help developers understand, recognize, and prevent common security coding errors that could lead to serious vulnerabilities in their applications. Although the last report was published in 2011, nearly all of the weaknesses cited are still relevant today.

Each of the 25 errors is accompanied by a wealth of information such as remediation cost, attack frequency, consequences, and mitigation techniques.

Payment Application Data Security Standard (PA-DSS)

In addition to the security and privacy requirements specified in the Payment Card Industry Data Security Standard (PCI DSS), the Payment Card Industry Security Standards Council also created a Payment Application Data Security Standard (PA-DSS) for software vendors who develop payment applications.

The PA DSS has fourteen requirements, which are listed on the next screen.

Payment Application Data Security Standard (PA-DSS) (Contd.)

The fourteen PA-DSS Requirements and Security Assessment Procedures are:

     1.  Do not retain full track data card verification code or PIN block data.
     2.  Protect stored cardholder data.
     3.  Provide secure authentication features.
     4.  Log payment application activity.
     5.  Develop secure payment applications.
     6.  Protect wireless transmissions.
     7.  Test payment applications to address vulnerabilities and maintain payment application updates.
     8.  Facilitate secure network implementation.
     9.  Do not allow cardholder data to be stored on a server connected to the Internet.
    10.  Facilitate secure remote access to payment application.
    11.  Encrypt sensitive traffic over public networks.
    12.  Encrypt all non-console administrative access.
    13.  Maintain a PA-DSS implementation guide for customers, resellers, and integrators.
    14.  Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel,

           customers, resellers, and integrators.

Cloud Security Alliance (CSA) Notorious Nine Report

The Cloud Security Alliance publishes the Notorious Nine, which is an up-to-date report on the top nine threats in cloud computing based on expert consensus and survey. Organizations can use this guide to make better decisions about the risks related to cloud technology adoption.

For each threat, this report describes threat implications, controls to reduce risk, and external links to additional resources.

Many, but not all, of the Notorious Nine have direct implications for application security, and development teams writing applications for cloud deployment can benefit greatly by reading this report for the latest cloud computing threats.

Cloud Security Alliance (CSA) Top 10 Big Data Security and Privacy Challenges

In 2012, the CSA published the Top 10 Big Data Security and Privacy Challenges report. It covers the following issues important to application developers:

     1.  Secure computations in distributed programming frameworks
     2.  Security best practices for non-relational data stores
     3.  Secure data storage and transactions logs
     4.  Endpoint input validation/filtering
     5.  Real-time security monitoring
     6.  Scalable and composable privacy-preserving data mining and analytics
     7.  Cryptographically enforced data-centric security
     8.  Granular access control
     9.  Granular audits
    10.  Data provenance


The Software Assurance Maturity Model (SAMM) is an open software security framework known as OpenSAMM. It helps organizations accomplish the following:

  • Evaluate existing security software practices.
  • Build a software security program.
  • Demonstrate improvements to a security assurance program.
  • Define and measure security-related activities.

Building Security In Maturity Model (BSIMM)

The Building Security In Maturity Model (BSIMM) is a study of real-world software security initiatives from companies such as Adobe, Microsoft, PayPal, and many others. It does not represent a security development model, but instead provides an aggregate of the experiences and lessons learned by the participating organizations.

BSIMM describes over 100 activities that your organization can implement. Those activities are organized in a free software security framework (SSF) that defines 12 practices organized into four domains: governance, intelligence, Secure Software Development Lifecycle (SSDL), and deployment.

The Governance domain helps organizations manage and measure software activities related to internal strategy and metrics, compliance and policy, and training.

The Intelligence domain provides proactive security guidance and describes organizational threat assessment and modeling.

The SSDL domain discusses essential software security practices to integrate into your own software development process.

The Deployment domain provides practices that are more aligned with traditional network security and software maintenance, such as penetration testing, configuration, and vulnerability management.

Comprehensive Lightweight Application Security Process (CLASP)

The Comprehensive Lightweight Application Security Process (CLASP) is an OWASP project. It defines a process to handle security issues and concerns early in the software development lifecycle. CLASP provides the following key resources:

  • Security best practices
  • Fundamental security goals and principles
  • Activities to improve your secure software development process
  • Secure software engineering roadmaps
  • A downloadable book and searchable vulnerability checklist for use by development teams

The Common Criteria for Information Technology Security Evaluation (CC)

The Common Criteria (CC) for Information Technology Security Evaluation is a certification standard for computer security products (ISO/IEC 15408). It defines a repeatable framework for specification, implementation, and evaluation of computer security products.

CC consists of the following three parts:
             –   Introduction and general model
             –   Security functional requirements (SFRs)/components
             –   Security assurance requirements (SARs)/components

CC helps validate certain security attributes of a computer security product, but does not provide a guarantee of actual security.

Sunday, September 27, 2015

Common .NET Interview Questions and Answers

ASP.NET Interview Questions


1. What is ASP.NET Application Life Cycle?

(IIS 5.0 and 6.0)
(IIS 7.0)
(Very Well Explained)

2. What is ASP.NET Page Life Cycle?

(Very Well Explained)

(Good Article. What you do in each of the events)

3. What is Application Domain? What is Application Pool? What are the differences?

How Application Pools Work (IIS 6.0)

Managing Application Pools in IIS 7


What is Application Domain

4. How do you bind the Master Page dynamically?

1. State Management in ASP.NET
2. What is the use of Master Page in ASP.NET
3. Authentication and Authorization?
4. What is CTS and CLS?
6. Diff between Cookie and Cache?
7. Talk abt SSL? Secure Socket Layer?

C# Interview Questions


1. boxing and unboxing
2. String and StringBuilder
3. Exception Handling
4. When to use Interfaces and Abstract Classes?



1. When we have ADO.NET, why do we need LINQ?

Design Patterns


1. What are design patterns? Types of design patterns?
2. What are Anti-patterns?
3. What is refactoring? Explain different refactoring techniques?
4. Creational, Structural, Behavioural Design Patterns?
5. Singleton design pattern



1. SQL Cache Dependency
2. ACID properties?
3. Ask to write a Self Join query for Employee Manager Table?

WCF Interview Questions


1. What is SOA?
2. What is WCF? Why do we need WCF? What is the adv of WCF? What is the diff between WCF and WebServices?
3. How to host a WCF Service?
4. Talk about contracts in WCF?
5. Endpoint in WCF?
6. How to generate Proxy for a WCF service?
7. Which is the namespace that you add first while creating a WCF service?
8. What is SOAP and why do we need it?
9. What are the different message exchange patterns supported by WCF?
10. When to use a MessageContract and when to use a DataContract?
11. List out the different bindings available in WCF?

MVC Interview Questions


1. What is MVC? What does M, V and C stand for?
2. What is ASP.NET MVC? Core features of ASP.NET MVC?
3. Which is assembly that defines MVC?
4. List different return types of controller action methods?
5. Explain Request Flow in ASP.NET MVC framework?
6. What is ViewData, TempData and ViewBag?
7. What are Action Methods in ASP.NET MVC?
8. What are Action filters in ASP.NET MVC? What are the different types? Sequence of Execution.
9. Explain MVC Application Lifecycle?
10. What is Routing in MVC? Explain Attribute based routing?
11. What is Bundling and Minification? How does Bundling increase performance?
12. What is Scaffolding?
13. What is CSRF and how do you prevent the same in MVC?
14. How do you implement Authentication and Authorization in MVC?
15. Difference between ActionResult and ViewResult?
16. Difference between each version of MVC 2,3,4,5,6?
17. How do we restrict MVC actions to be invoked only by GET or POST?
18. What is the difference between HTML.TextBox and HTML.TextBoxFor?
19. Use of Keep and Peek in TempData?
20. How to send result back in JSON format in MVC?
21. What are Partial Views in MVC?
22. How do you do validations in MVC?




Wednesday, August 19, 2015

High Level Design Documentation Template

Document Revision History

Requested By
Created By
High Level design document draft
Your Name

Revision Level
Revision Date
Description of Revision
First Draft

 abc kumar

NewLease® is a trademark of XYZ, Inc.
Proprietary and Confidential Information/Copyright Notice. This work contains valuable, proprietary, and confidential information of XYZ, Inc. Disclosure, use, or reproduction outside of International Decision Systems, Inc. is prohibited except as authorized in writing. This unpublished work is protected by the laws of the United States and other countries. The work was created in 2011.
Permitted Uses. This documentation may be reproduced, duplicated, and distributed in electronic and/or printed format by any licensee of XYZ, Inc. or licensee or sub-licensee of an Affiliated Corporation of XYZ, Inc. (collectively "XYZ"), provided, however, that the following conditions are fulfilled:  (i) all copyright and other proprietary notices included in this documentation appear clearly and distinctively on all reproduced, duplicated, and distributed copies; (ii) this documentation is kept in its entirety and without modification or/and alteration; and (iii) this documentation is distributed only to officers, directors, or employees of an XYZlicensee or sub-licensee, or an XYZ licensee or sub-licensee's affiliated corporation. For any other use, authorization must be requested and obtained from XYZ.
Third Party Trademark Acknowledgments. Products and services that are referred to in this documentation may be either trademarks and/or registered trademarks of their respective owners. Neither XYZ, Inc. nor any of its Affiliated Corporations make claim to these trademarks.
Table of Contents
Introduction........................................................................................................ 6
High Level Design Document Overview.................................................................... 6
Audience........................................................................................................... 6
HDD (High Level Design document) Update Policy...................................................... 6
HDD.1      Availability Trigger Process Overview...................................................... 7
1.1         Availability Trigger Process Overview & Scope of the work................................ 7
HDD.2      Availability Trigger Design Details............................................................ 8
2.1         Windows Service Trigger............................................................................ 8
2.1.1     Fetch the Active Facility Data & Form the request....................................... 8
2.1.2     Actuate the existing web service & Transform the Response......................... 8
2.1.3     Database Insertion................................................................................ 8
2.2         Database Objects...................................................................................... 9

High Level Design Document Overview

This business has an approval rate between 30-50% and as such the goal of the scorecard is to allow the SFSI Credit team to make the quickest, most accurate credit decision possible on the non-Financial Statement transactions.  These are transactions which are under $250K or $350K in exposure (based on business line).  SFSI on the whole gains from an operational and cost perspective when they can make the quickest, lowest touch decision on whether to extend credit to these applicants.

Conceptually, the process overview is as follows

This document will cover the high level technical solution to create a custom web service to achieve the scorecard functionality being requested by XYZ inc.

·         The scorecard must provide a recommended decision on each application that falls into one of three categories:  Recommended Approval, Recommended Decline, Manual Review.
·         Any exposure amounts above the business line thresholds (aka Financial Statement transactions) will automatically qualify for “Manual Review” status. We would like the transaction to still go through the rate card.
·         Any transactions not meeting the Credit Filters recommended decision of “Recommended Approval” or “Recommended Decline” will automatically qualify for the “Manual Review” recommendation. With “recommend decline” can data that caused recommendation be highlighted in some fashion?

In Scope

Not In Scope

Flow Charts

Internal test environment details:
Customer test environment details (DEV/UAT):
These three interfaces should be setup on the following internal server:
-       Database server:
-       Database Name :
-       App and Web server:
-       On the application server, XYZ URL:

Note: XYZ will share later.

Test account credentials for bureau interfaces:
Details have been provided for configuring bureau test environment connectivity in the prior “Bureau Connectivity Details” section.

Prod account credentials for bureau interfaces:
This information has been requested from XYZ along with test accounts for their own use.
All deliverables are SMART: specific, measurable, achievable, realistic, and time-oriented.

Acceptance Criteria
Due Date
Reviewer/ Approver
An interface to be able to successfully pull a D&B BIR report.
 users will review and accept

Lead/Tech Consultant
Ability to successfully pull a PayNet Direct report.
users will review and accept

Lead/Tech Consultant
Ability to successfully pull an Experian Personal Credit Report
 users will review and accept

Lead/Tech Consultant