General design principles

Software Development
#1

Hello Everyone,

In this blog we will learn about some General design principles.

Read these carefully:

• Prefer to use policy based declarative security instead of programmatic security: separation between security configuration and business code. Beware that both business code and the security configuration typically have different life cycles and implemented/managed by different people.
• Use declarative security instead of programative, separation between application logic and the cross-cutting concerns (e.g. security, logging).
• Prefer to use message level / end-to-end security (e.g. WSS) than transport level / point-to-point security (e.g. SSL): to protect the messages in the intermediate services and flexibility to protect only portions of the messages (due to performance).
• Does the service/data need authentication, authorization, signature /non-repudiation, encryption ?
• If the web service is used to wrap a legacy service : aware about vulnerabilities of the legacy service, aware about how to reconcile the security model (e.g. credentials/roles mapping) or some legacy application doesn’t have any security provisioning at all
• Use white lists instead of black lists
• Throttling the requests / messages-size to prevent DoS
• Defense in depth: don’t rely on a single layer of security (e.g. apply also authentication & SSL instead of protecting the infrastructure with firewall only)
• Check at the gate (e.g. validate and authenticate early )
• Secure the weakest link
• Compartmentalize : isolate and contain problems e.g. firewall/DMZ, least privileged accounts, root jail.
• S ecure by default e.g. close all ports unless it’s necessary
• Communicate the assumptions explicitly e.g. firewall will secure all our internal services with no ports open to outside world
• Understand how the infrastructure restriction (e.g. firewall filtering rules, supported protocol, ports allowed) will affect your design
• Understand the organizational policies/procedure (e.g. what applications and users are allowed to do) so you don’t have acceptance problem by production team because your services breach these policies
• Understand the deployment topology due to your organization structure (e.g. your company has many remote branches offices connected to the main server-farm via VPN)
• Understand the identity propagation / credential mapping across trust boundaries (e.g. apache web account > weblogic web service account > database account)
• Security measures (e.g. authentication, encryption, signing) will cost performance (increasing processing cost and message size) as well as other qualities attributes such as usability, maintainability (e.g. distribution of certificates) and operability (e.g. security service / identity provider failure). So consider the trade off between security and other quality attributes regarding your company infrastructure and policies (e.g. if the firewall policy in your company is very strict, you might lessen the encryption requirement for the intern services).
• While applying security by design , I still keep the "security through obscurity " to some extent, e.g. I will not publicly publish the security architecture of my company (the endpoints/ports, wsdl/schema, libraries used, etc).

Thankyou.