Table of Contents
- Why Security
- Acronyms & Terminology
- Security Layers Architecture
- Secure Entities
- Security Threats
- Security Context
- Separation of context
- Beyond Service Account Framework
1. Why Security
Software Applications are built and run in millions nowadays on a variety of platforms. These applications are open to all kind of users ranging from developers, own employees, customers, end users, random users, professional hackers etc. So, applications which are open in internet are more prone to unauthorized uses & malicious threats, which challenge the application every now and then by the process of stealing confidential data from applications, creating junk data, modifying control data, and applying heavy loads, corrupting and brining done systems, or take control of the system remotely. As the old saying goes, prevention is better than cure, so, it is wise to enforce a threat modeling before commencing any system application design and to mitigate such attacks which may exploit configuration weaknesses that prevail in different servers in the application clusters. By means of security, we propose to uniquely identifying the clients of your applications and services. The correct users only are able to process the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. The audit data are equally important to perform business rule validated actions. For example, if a user is allowed to take a bank statement just once per month, under no circumstance, should he be allowed twice. This also elaborated to keep his data private, no other persons can read it. The data integrity is another form of security threats where no user can accidentally or deliberately do the data modification. There are some thoughts that legal users should never be denied of their information, even if there are some attackers with denial of service attacks to crash an application.
2. Acronyms & Terminology
|Term ||Meaning/Expression |
|Asset ||A resource of value, such as the data in a database or on the file system. A system resource. |
|Attack/ Exploit ||An action taken by someone or something that harms an asset. This could be someone following through on a threat or exploiting vulnerability. |
|ACL ||Access Control List |
|Countermeasure ||A safeguard that addresses a threat and mitigates risk |
|OS ||Operating System |
|Threat ||A potential occurrence, malicious or otherwise, that might damage or compromise your assets |
|Vulnerability ||A weakness in some aspect or feature of a system that makes a threat possible. Vulnerabilities might exist at the network, host, or application levels. |
|MDI ||Multiple Document Interface |
|WinForm ||Form Application runs on Desktop/Laptop without any help of any supported windows service. They are found in executable form. |
|ASP.NET ||.NET version of application which runs in conjugation with IIS hosted in Window Server |
|IIS ||Internet Information Server is made for windows hosting of an web site |
|AD ||Active Directory |
3. Security Layers Architecture
Based on the application architectures, the security layers can be defined and applied in a variety of forms. This paper is based on applying security around a typical n-tier ASP.NET application which is distributed over multiple technologies and platforms and physical networks. The architecture can enforce a layered security approach to mitigate security threats from within the network and outside of the network. The security solution is based on distributed application already implemented on Microsoft technology supported by ASP.NET, ADO.NET, IIS 6.0, WCF, Web Service, COM+, MSMQ, SQL Server 2005, and Windows Server 2003. Though the server and services of future may vary in versions, the implementation of security approach remains same in the place. Let us look at the architecture of the application.
Example-> Diagram 1: Architecture of Mixed Platform ASP.NET application
4. Secure Entities
The compromise of security can happen on multiple access points ranging from user interaction to own user who may be a threat to the applications. The malicious intentions are typically applied on a variety of computing resources which includes hardware & software components. User interaction in the form of malicious attack is landed in three categories in a typical ASP.NET application which we would like to make secure and robust. They are as follows:
- A web browser or a third party desktop application
In modern days, there are several web browsers that have made their presence into the market. The major ones are Internet Explorer, Mozilla Firefox, Opera, Safari. These entities belong to internet users, so we don’t have many options to control them.
- Web Servers
The current solution is based on ASP.NET web application. The application serves web forms to users who use browsers to read and write the information to the application. Windows Server 2003 enterprise edition with service pack 3 would be an example of the server. Inside the server, there are other resources which need to be secured. For example, Shares folders Auditing and Logging, Services, Files and Directories, Registry, Accounts, MSMQs and other window components like COM+. This component can be remotely administered, so providing an encrypted channel of communication and using IPSec to limit the computers that can be used to minimize any attack on them. We can limit the number of Administration accounts. However, I am keeping this out of the scope of this paper.
- Corporate Client Application
They are the desktop version of application. They can be MDI or a dialog based WinForm/WPF application. They are executable and directly run from Laptop or a Desktop. No browser is needed.
- Network & Firewalls
The client computer, web servers, proxy servers, applications, database servers are connected by networks and thus insulated by firewalls. The computers belong to a domain for which there will be an Active Directory. The given users and computer can exist in on domain. Typical example is “
web01.domain.net”, a machine “
web01” can be called as “
web01.intranet.domain.net” and person “
user1” can be called as “
email@example.com”. Protocol and port are major examples to be secured for router, switch, firewalls.
Typically, database is used to store data related daily customer transactions or master data that control the applications. There are many good databases available in the market like SQL Server 2005, Oracle 10g, and MySQL 5.0, etc. In the solution, we will be referring to SQL Server 2005 enterprise edition. Database contains most valuable data which belongs to the client. Data are spread over multiple files over the networks. The data must be kept physically and logically secured, so that no unauthorized person can access it.
- Application Servers
They are again 32 bits Windows Server 2003, though this can be upgraded in for other performance issue. For simplicity, we will be continuing the solution with Windows Server 2003. They are typically installed with IIS, MSMQ, and Security Alerts, etc.
- Application Itself
The application is first contact and major concern of attack. So, any user request in any form to the application must pass the security check. There are several areas which can be targeted by hackers or malicious users.
5. Security Threats
The users with malicious intent can access resources or data which do not belong to them. With the architecture in the above diagram, the application looks unsecure enough to break into. (There are some links that exist, which are not depicted in the diagram. For example, a link exists from internet user to application server or database server.) The person who gained the access of web server can easily break into data layer of application and can access SQL Server from there.
There are many tools and proven technology employed in the IT infrastructure in the software application deployment. The perceptions are that these work very well to cut down any security threats. This is true by all means, but due to adherence of usage policy, the security is breached and loops and holes are revealed.
The most known model to understand where a security lap happens is STRIDE. Security Threats of an application can be categorized based on the goals and purposes of the attacks. Providing the brief of these attacks which can be mitigated by ASP.NET application by support from the framework itself. However, a detailed discussion is out of scope of this paper.
- Spoofing. Spoofing is providing a false identity to gain access on behalf of others. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin. The service account implementation can take care of majority of this attack either from the internet as well as intranet/local machine code.
- Tampering. Tampering is the unauthorized modification of data. These portions of attack are handled by ASP.NET native implementation. ASP.NET has employed various mechanisms like UI validation, XSS validation, View State encryption, one-way hashing of configuration data to curb those attack.
- Repudiation. Repudiation is the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Authentication & authorization matrix will be very good implementation for these kind of attacks.
- Information disclosure. Information disclosure is the unwanted exposure of private data. Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system level details being revealed to the client. Any of this information can be very useful to the attacker. This is implemented through global.asax error handling modules and interpreting actual exception to a user specific error message. Do not reveal internal system or application details, such as stack traces, --- SQL statement fragments, and so on. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. Fail securely in the event of an exception, and make sure your application denies access and is not left in an insecure state. Do not log sensitive or private data such as passwords, which could be compromised. When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it. For example, if you return an HTML error message, you should encode the output to avoid script injection.
- Denial of service. Denial of service is the process of making a system or application unavailable. We can make sure the TCP/IP stack configuration on your server is hardened to protect against attacks such as SYN floods. So, configure ASP.NET to limit the size of accepted
POST requests and to place limits on request execution times.
- Elevation of privilege. Elevation of privilege occurs when a user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. So, service account implementation is the backbone of this architecture to provide security over the system.
6. Security Context
The job of architecture is to provide component to component service strategy to resolve a business workflow with high level of scalability, integrity, stability & availability but without compromising security. By this means, it roughly means to execute each line of code in that executing component under a known the user account who owns the activity. So, if the surface area is reduced in application, we can always ensure no more applications run on the server in unknown account. So the scope of unknown code remains a least possibility. There is a need to carry the user context in every bit of component and access check in the code side will ensure no unauthorized code executes on legitimate account.
6.1. Flow of Security Context
The security context flows from existence of a user of the system to his data store. User Identity is mapped to a security context which is carried with call whenever executions take place in the applications. By that means, data or computer resources should be operated by valid users who have derived logical rights to access the data or resources. Else the user can do harm to data or resources which do not belong to him at all. The security context is created when a user exists and he or she starts interaction with the system. The security context is initiated from user interface which is then by authenticated by a program and authorized by another program to access a set of resources. Authentication and authorization of such user actions are handled by application security framework which can be a placed centrally within a system or an external providers or in a mix mode. ASP.NET framework provides the mechanism to do the authentication and authorization part. They can be extended by Membership providers which are pluggable. The logical stack of context flow would go like this diagram provided below:
Diagram 2: Logical Architecture of Security Context
The context will then follow with the user data from among heterogeneous components within the applications. The code at the application will always execute in some user context. If it is a desktop environment, the user context is a logged in user who is local to the system or has an access to login to the system. If it is a window service or batch job, the service or job always configured while creating the services. However, a code can always impersonate to other users which can pose a great risk to security. So, configuration of such code is made highly secured by configuring service account (Described in section 6.4). The security context communication between two components can happen in two ways.
6.2. Synchronous Call
In distributed applications, most of the participant components communicate with each other with a synchronous call. So, a security context flows from one component to other in the form of domain trust, certificates, headers or method parameters. So, the client reaches to the server component with security context, and server responds to the client immediately if the security context does not match the requirement. So, server can impersonate the call or map the client user context with server user context. Since the internet has grown to a vast number of users, the current solution will go for second one and, impersonation will be used when building an intranet application. The mapping of user will be per service basis where domain account will be used to run those services so that the user can be controlled by administrator remotely and no local user can penetrate in the server and execute any code there.
To ensure any external user goes into the web server; remove all the access to local user, inbuilt users on the machine. So, request from internet to a sever goes via security context by invoking some request to the applications by some user interface, e.g., a Browser. With the example given above security context, when a user exists, he can browse the ASP.NET application which is hosted in web server. User logs in at terminal like desktop/laptop/mobile, etc. The OS on the client machine then create a security context on his behalf and the context travels on the wire to reach web server where ASP.NET application resides. The web server is running in another security context, on behalf of another trusted users, typically as the user is a local user created in the web server. Typically, this is run on anonymous account for form based ASP.NET application. So, every call from a browser will run ASP.NET code in user
IUSER_MachineName user which is inbuilt on the server. To eliminate any unknown user invokes any code in web server; create new the security context in defined service account which is typically a domain user with least privilege. For default privileges of web account, refer to http://support.microsoft.com/kb/812614. The account is configured at IIS level.
So, the intention is to run the user code in context of user who operates on his data, resources on which he has permission. An unauthorized system access will break the rule and is an exception. Every action is to be performed with context of defined set users.
Diagram 3: Configuring User Identity at Application Pool Level
The system resources are configured with service account at IIS level for low level access.
Diagram 4: Configuring User Identity at Web Site Level
For more fine tuning of every low level resource, Web Site permission can be granted or revoked.
Diagram 5: Low Level Access to Website
If the IIS even allows the security context flow to the system / code, service account still needs little more access to execute the code. So, a malicious intent user security context will be eliminated at this level. And next challenges remain with proxy users who are valid users either authenticated previously or it is a UI level attack. For UI level application attack, validations of user inputs are best solutions. These parts of security are managed by ASP.NET form authentication, authentication and authorization module. These discussions on Input validation, Authentication, Authorization, Configuration Management, Sensitive Data, Pen Test, XSS attack, SQL injections are not in the scope of this paper. Though there are several improvements in IIS7 / Window Server 2008 to minimize surface area risk to security to the system, still we want to safeguard our application from malicious user inputs.
A window service is configured in a different way. The install utility or MSI creator defines the service accounts to be use. This is optionally also available in verbose mode of MSI installation. If these account configurations are not available during installation, they are configured in service console.
Diagram 6: Location User Window Service Host
To configure user account in any window service (for example: Google Update Window Service), locate the service in Service Console and right click on that to pop-up configuration console.
Diagram 7: Configure Service accounts to Window Service
Then go to Log on tab, there are two options available in user accounts. A local System account is already configured which we don’t want. The account is a privileged account and local user. The same user cannot be controlled by Active Directory as well. So, we configure a newly created account mydomain\myaccount in active directory with
Run as a Service Privilege. Service Accounts are described in Section 6.4.
6.3. Asynchronous Call
These calls are executed in workflow. Queuing Process does not depend on user interaction immediately. The user context is abstracted and confined in a self extracting token which is used by serving component. The system job or services invokes on behalf of the users. Under no circumstance, the code runs in context of generalized users where the actions is performed by authorized roles or users.
On asynchronous operations, greatly MSMQs are preferable choice as these objects provide the good amount of durability, scalability, resilience and stability over transactional operations. Since these can exist in distributed components and endure the breakdowns and recover, we go for these kinds of solutions. The risk is, an unknown user can read/write messages from the MSMQs. To minimize the attack, service accounts are placed in queue management console. Public queues are domain controlled and thus they are configured through Active Directory. So, a system administrator can easily detect and change the behavior of the MSMQs. However, private MSMQs service account are bit tricky and need manual configuration on the local machine.
Diagram 8: MSMQ configurations
So, the application reading the MSMQs are configured with service account only can read the messages and everybody else just be denied the access. So, no unknown/unauthorized person can read/write any messages there in the MSMQ.
6.4. Service Accounts & System Users
The context flows from one component to another component in the form of user identity. So, to minimize unknown or anonymous user to do that, our first policy is to name the user who is making the request either synchronously or asynchronous in either from outside of the system or from within the system itself. So, define the user identity which is visible from all the physical server and networks.
Active Directory would be best place to keep the user information. Service accounts are created as domain users a system administrator can enter, modify and drop them. This is the most critical nerve center of all security of this design. So, physical security is must for this kind of environment and must be periodically audited. A system administrator will keep a watch on services accounts, and in case of any defaulter service account, the account is deleted. The service will suspend its execution if it tries to execute any code on behalf of this account. The information is available immediately to all servers in the network, e.g., web servers/app servers/db servers.
6.4.1. NT Users
NT users are nothing but active directory users with limited access to local computers. They are used to run the code on behalf of actual actor/user. Service accounts are defined with limited service rights to execute the database operation. No user of these service account categories should have administrative privilege or login privileges. With this policy, the user code does not do many things itself to reduce the risk.
6.4.2. Database users
NT users are also valid DB users if logins are created in Database Servers. Some of the service accounts can access database for read/write operations. These logins are created and maintained in SQL databases. This can greatly help to restrict SQL injection. However, in some scenarios, we do not need a user to be trusted user. So, as an exception, a SQL user can be created in SQL server, so can be strictly used in restricted manner when no security threats are expected.
7. Separation of Context
To achieve high degree of security on distributed application which is over multiple domains, several web servers, application servers, and database servers, the system needs careful planning of vulnerable resources and threat assessment. The key resources are listed and specific users are identified who can access those resources. Even though a hacker can place a piece of code on the server by some unfair means, still the code will not be to do much because of unknown security restriction. There are several access matrixes which are applied on the architecture to ensure no unauthorized user executes his code on the systems. The Matrix contains operation name, user name and access rights. The matrixes are to be prepared in line with functional domain so that transition among actual system user becomes smooth. There are few of matrixes used in solution placed here. They are self-describing.
- Application vs. Operation Resource Matrix
- Application vs. System Resource Matrix
- Service Account vs. System Services
- Service Account vs. Low Level System Resource Access
- Service Account vs. Database Access
Example of Application vs. Operation Resource Matrix
|SL ||Name of the Operation ||
|Writer ||Reviewer ||Publisher ||Reader ||Troubleshooter |
|1 ||Add Content ||Yes ||No ||No ||No ||No |
|2 ||Review Content ||Yes ||Yes ||No ||No ||No |
|3 ||Publish Content ||No ||No ||Yes ||No ||Yes |
|4 ||View Content ||Yes ||Yes ||Yes ||Yes ||Yes |
Example of Application vs. System Resource Matrix
|SL ||Name of the Operation ||
|svc_web1 ||Svc_db1 ||Svc_quque1 ||DBA ||Administrator |
|1 ||Run a Service ||Yes ||No ||Yes ||No ||Yes |
|2 ||Logon on a Terminal ||No ||Yes ||No ||No ||Yes |
|3 ||Read/Write to Disk ||No ||No ||Yes ||No ||Yes |
|4 ||Send a Mail ||No ||Yes ||Yes ||No ||Yes |
|5 ||Write a MSMQ ||Yes ||No ||Yes ||No ||Yes |
|6 ||Access Database ||No ||Yes ||No ||Yes ||No |
Example of Service Account vs. System Services
|SL ||Name of the Service ||
|svc_web1 ||Svc_db1 ||Svc_quque1 ||DBA ||Administrator |
|1 ||Website (http://www.serverdomain/) ||Yes ||No ||No ||No ||No |
|2 ||ContentServerHandler Service(WCF) No ||Yes ||Yes ||No ||No |
|3 ||ContentComponent (COM+) ||No ||No ||Yes ||No ||No |
|4 ||Mail Component ||No ||Yes ||Yes ||No ||No |
|6 ||Database Service ||No ||No ||No ||No ||Yes |
Example of Service Account vs. Low Level System Resource Access
|SL ||Name of Low Level System Resource ||
|svc_web1 ||Svc_db1 ||Svc_quque1 ||DBA ||Administrator |
|1 ||Disk IO ||Read ||Read/write to specific folder ||Read/write to specific folder ||No ||Yes |
|2 ||System Registry ||No ||Yes ||Yes ||No ||Yes |
|3 ||Event Viewer ||No ||Yes ||Yes ||No ||Yes |
|4 ||Remote Login ||No ||No ||No ||No ||Yes |
|5 ||Log on as A Service ||No ||Yes ||Yes ||No ||Yes |
|6 ||Log on as Batch ||Yes ||Yes ||Yes ||No ||No |
Example of Service Account vs. Database Access
|SL ||Name of the Database ||
|svc_web1 ||Svc_db1 ||Svc_quque1 ||DBA ||Administrator |
|1 ||Login to DB Server ||No ||Yes ||No ||Yes ||No |
|2 ||Execute Stored Procedure ||No ||Provide SP Name ||No ||Yes ||No |
|3 ||db_owner ||No ||No ||No ||Yes ||No |
|4 ||Database Reader ||No ||Provide table name ||No ||Yes ||No |
|5 ||Database Writer ||No ||No ||No ||Yes ||No |
|6 ||Sys_admin ||No ||No ||No ||No ||No |
This matrix will be the basis one and can be extended in a given project. Fine tune of the security should not be hindrance to other n-bility of the architectures. However, for optimization and maintenance, these are extended with role management. They are described in next sections.
7.1. Role Management
When the user base grows, they sometimes become unmanageable with their access rights, especially with domain level access. So, a role mapping with user can serve the purpose. The user / role mapping matrix is not a new concept, so I will not discuss it here. However, they can inherit from database point of view, application point of view and OS point of views. Role management can be beneficial to control the access.
7.1.1. Window Authentication or NT Roles
There are some inbuilt groups available in the OS level; they can be used to the scenario. We can add more groups like
DBReaders and add user into these groups. The Services running for a web handler would not access databases at all. The users belong to AD of the target domain of deployment of production environment.
7.1.2. Application roles defined within application domain
Application related roles can be grouped around domain operations like
FeedbackProviders, etc. Configure server applications to run using least privileged accounts. For services, Roles are either implemented with AzMan providers or at Enterprise level by enabling COM+ role-based security, and enforce component-level access checks. To secure the traffic passed to remote serviced components, use IPSec encrypted channels or use remote procedure call (RPC) encryption. Restrict the range of ports that Distributed COM (DCOM) dynamically allocates or use static endpoint mapping to limit the port range to specific ports.
7.1.3. Database roles
There are some inbuilt roles available in the database level like
db_datawriter, etc. These roles can be used for the scenario or can be extended by application roles where a user can do some reads and cannot perform some writes. These can be inherited from Application roles as well and then can be extended. Like
ContentWriter cannot execute publish sorted procedure,
FeedbackProviders can read execute
Read stored procedure. The grouping of all
StoredProcedure and mapping between roles are prepared in advance while designing the system.
7.2. Access Control List Optimization
Edit access control list of OS resources with role and service account to allow certain number of permissions. These can reduce and impact large number security attack on the system and eliminate the attack. For example: SQL injection. They are inevitable even if there are rigorous amounts of UI validations. So, service account access control list can restrict access to component level task and DB level operations.
7.2.1. File System Resource & Share folders
Write least privileged code, regardless of the account used to run the code. Use code access security to constrain the resources and operations that your code is allowed to access, either by configuring policy or how you write your code You can use code access security to constrain an assembly’s ability to access areas of the file system and perform file I/O.
7.2.2. Network resources & Ports
User profile can easily restrict network resources & proxy fire walls. The domain boundary will ensure the security so that appropriate user can get an access to the system. Cross domain access is restricted and only known users can be allowed to read/write remote systems. Use Internet Protocol Security (IPSec) or SSL to secure the communication channel between the Web server and the application server, and between the application server and the database server. Restrict the range of ports with which clients can connect to the application server, and consider using IPSec restrictions to limit the range of clients.
7.2.3. System Registry
System registries are only writable by local user, so application running on domain user would not be able to read write and system registry values. So, careful planning of accounts and registry node to be accessed matrix would give fine grain access to the system.
7.2.4. Active Directories
Active Directory is managed by system administrator, so not facing to internet. However, a physical security has been in place and company policy would be strong enough to audit its working. All these service accounts, servers, networks, MSMQs must belong to this directory. Resources outside of these directories would not be allowed to execute anything on the physical servers.
7.2.5. MSMQ & other OS Resources
MQMQ and other resources used in the system should be registered in Active Directory. However, if there is a private MSMQs, the domain users must be added to its access control list and anonymous & everyone access must be removed.
7.2.6. Logs & Audits
Logs are Audits are kept highly encrypted and secured all the time. The frequent audits are to be done to ensure proper security policy is never compromised.
8. Beyond Service Account Framework
The paper does not conclude any significant usage unless we have some third party assurance and testing. For writing code, it is just a code review tool that can certify if any security exceptions is reported. No amount of code review can eliminate fully vulnerability of code, deployment, hosting and maintenance. You can restrict what code can do regardless of the account used to run the code. You can use code access security to constrain the resources and operations that your code is allowed to access, either by configuring policy or how you write your code. If your code does not need to access a resource or perform a sensitive operation such as calling unmanaged code, you can use declarative security attributes to ensure that your code cannot be granted this permission by an administrator.
The building up of trust and high level of work ethics can minimize the security threats. The physical securities, Anonymization of database are major concern of data security, and thus can dangerous if not handled properly. More importance is given to Session Management, Cryptography, Parameter Manipulation, Exception Management in such a way that no domain or application related information is presented to anonymous user. A testing tool is always preferable to run a test. HP-Web Inspect can do a great job to identify the security holes in the systems. No amount of security constraint proved sufficient so far, still we hope to stop all the loop holes on the applications. I have covered most of the areas where threats might land onto. However, if any unfair element finds a place his/her code to execute his program inside any place of this architecture; I would like to seal those. So, any assessment is welcome.
This is robust security framework applied to the enterprise level system. The optimizations have to be taken care of to ensure that there is no degradation of application performance. If any risk is taken in favor of performance, these must be audited & logged periodically and discussed in maintenance meetings.