Security Policy for Security ASP
Why does ASP need security policy?
In the process of security management of ASP, there must be a channel to pass the existing state of any given point in time. Security policy plays this role. They are written representations of current security requirements and guidelines and steps that the ASP has consistently used. A consistent strategy will make the ASP internally aware of what must be done in terms of security. If the ASP is to see a rapid improvement in security state, the establishment of a security policy is a logical step after evaluation and should be initiated as an adjunct to security planning.
When planning for security management is expanded, specific factors in the environment will change. When changes occur, the policies are checked and modified to ensure that they pass the current plan to protect the ASP environment. The security policy must be checked at least once in 6-12 months, as well as whenever a policy change is required for a variety of reasons. Therefore, a security policy is an ongoing effort.
Steps to develop ASP security policies
The following steps are the basic steps in defining a security policy.
Understand what the security policy consists of.
Security policy defines how an ASP manages, protects, and assigns sensitive information and resources
Before connecting to the Internet, any ASP should develop a policy that explicitly specifies the solution to be used and how these solutions are used
The strategy should be clear, concise, and easy to understand, with built-in mechanisms for changing policies (flexibility)
Default policy: Do not use it unless explicitly permitted
Understand what requirements the security policy must adhere to.
External customer requirements defined in the service level agreement
External legal requirements related to security
External vendor Security Policy
Internal ASP Security Policy
Internal/external security policies in the context of integration of ASP and customer environments
Understand how security policy should be considered and determine what to protect.
Computer Resources
Key Systems
Sensitive systems
Customer and company data
Key data
Sensitive data
Public data
Determine the guidelines for security policy.
Develop a two-level strategy
High-level policy
Write from the customer's perspective
Keep it simple
Avoid technical terminology and include an explanation of it
Low-level policies
Written for the perpetrators
Detailed technical instructions on how to perform
Include filter rules, etc.
Security policies must be based on the actual conditions of the ASP customer, which should be clear, consistent, concise, and easy to understand.
Provide regular inspection and inspection
Management of ASP Services
Customer Relationship Management
The content of customer relationship management is to develop and cultivate good professional working relationship between client and ASP. Customer relationship managers must intervene in all other aspects of MOF. For example, a customer relationship manager facilitates interaction between the ASP and the customer during SLA negotiations and participates in resolving customer dissatisfaction with the services provided. This is a selling point for customer relationship managers if the customer relationship Manager delivers a solution that is truly secure.
Communication with customers is the main aspect of the security management of CRM.
Service Management
All the actions taken during the security management process depend on the agreed service levels in the service level agreement. Service level management ensures that agreement is specified and implemented on the services provided to the customer. The goal is to create an optimal IT service that enables customers to meet their expectations and requirements for IT services, and to adjust the costs associated with both the ASP and the customer.
The SLA must also include a section that provides an agreement on the security measures to be taken (see the Framework for the Safety Section in the appendix). From a security standpoint, there are some activities that need to be checked for service level management.
Identify the customer's safety requirements and expectations.
Verify the feasibility of these security requirements and expectations of the customer.
Negotiate the security level records required for recommendations and IT services.
Identify, draft, and establish security standards for IT services.
Monitor these security standards.
Report on the security effectiveness and status of the services provided.
Access to security feedback and assessment.
For more information about the relationship between CRM and service management, see ITIL library:http://www.itil.co.uk/
Change Management
Managing changes is an important aspect of maintaining the system's normal operation and integrity. The change control process provides an opportunity to approve the changes and take a comprehensive look at the changes to the request. This analysis enables the assessment of security risks.
Defined changes and purposes
The written definition of the work to be done or the changes to be implemented should be completed. This should include the purpose of the change, the outcome of the change, and the expected impact on other systems. This definition is used by the security process to determine the effect of security.
Risk assessment
For the changes that will be made, you need to complete the risk assessment. The scope of this security risk assessment can range from risk-free to high risk. As part of the risk assessment, the security risks also need to be evaluated and their impact on the ASP business needs to be determined.
Approval process
Security administrators are responsible for approving changes for security considerations. Without his approval, the changes will be rejected (unless an additional security countermeasure is defined to meet the contingency conditions).
To verify changes
You need to use information about the steps to verify that the changes you make have the required security. After you implement the changes, you should follow the steps and take action based on the predefined results.
Security Incident Management
Security Event Management is a special part of the general event management. Most importantly, the ASP has the primary contact point for a security incident. This means that there must be a location where all security events are registered, and all ASP employees and customers (if necessary) must know this location so that they can handle security events at that location. There must be a step to a security incident that will make it clear what happens when a security incident is claimed to have occurred.
The event controller must have a task report script that describes the security incident issue. According to this task report script, the event controller will conclude that this is a security event, not a security event, or that he cannot determine the event. Security event processes and procedures must be performed when a security event is confirmed or not determined. Don't take risks when it comes to security incidents. The description of the security incident process and the steps requires a joint effort of security management and incident management.
The steps to take after discovering an event are:
Registration, need to register the basic event details, and alert the expert group as needed.
Classification and initial support; it is necessary to obtain information from the latest configuration Management database (CMDB) to determine what type of security event is occurring. A check is also performed on the last event information.
Investigation and diagnosis; If the earlier check does not provide the required information, start a more rigorous investigation of the updated security incident details and configuration details to determine what type of security event this is. Start diagnostics, and you must work out a clear solution.
resolution and recovery; There must be a solution at this point. When you resolve a security event that requires any changes, the change process must respond urgently to the change request.
The event was terminated, at which point the initial event was resolved. Information about the event is correctly documented for use when the security event may reappear.
The people involved in this security event management process (emergency administrators, security administrators, event controllers, support personnel) must all understand how to do when security incidents occur. They must also be aware of the time limits that can be used to resolve security events. There are descriptions of these timelines (service levels) in the ASP and customer-defined SLAs.
Contingency planning
The contingency planning process is responsible for the development of disaster recovery plans. But from a security standpoint, ASPs want to ensure that accurate action is taken when a disaster occurs. Therefore, you need to define something, such as the security aspects of the contingency plan, the parts of the ASP or customer organization that could be destroyed by the disaster, and the parts of the organization that are not allowed to be destroyed by the disaster (since that would mean that the organization no longer exists). What is the SLA's rules for this?
The key in this process is to train all the employees involved in the emergency process. In a crisis, there is little time to make a decision, so you must be familiar with the emergency process as well as familiar with daily work.
The white Paper on ASP Contingency planning provides a more in-depth overview of how to manage the emergency process.
