Cloud-10 Infrastructure Security - Revision history

Ove Hansen: /* R9:Infrastructure Security */

2010-05-24T13:23:23Z

‎R9:Infrastructure Security

Ove Hansen: /* R9:Infrastructure Security */

2010-05-24T13:03:14Z

‎R9:Infrastructure Security

Ove Hansen at 14:31, 17 May 2010

2010-05-17T14:31:14Z

Ove Hansen: /* R9:Infrastructure Security */

2010-05-17T14:22:38Z

‎R9:Infrastructure Security

Vinaykbansal: Created page with '==R9:Infrastructure Security== Category:OWASP Cloud ‐ 10 Project NOTOC '

2009-11-16T13:22:57Z

Created page with '==R9:Infrastructure Security== Category:OWASP Cloud ‐ 10 Project __NOTOC__ <headertabs/>'

New page

==R9:Infrastructure Security==

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

@@ Line 9: / Line 9: @@
 <br>
-#Default configurations of systems and network devices
+#Default configurations of systems and network devices. A system, application or network device "fresh out of the box" is likely to be running old versions of its software, and not be up-to-date with regards to security updates. Furthermore, standard configurations, passwords, exploits etc. are well known and the details of those circulate freely on the Internet, and will mean these systems are much more likely to become compromised.
-#All services, even active, unused ones, may contain security related bugs that potentially can be exploited.
+#All services, even active, unused ones, may contain security related bugs that potentially can be exploited, and malicious parties are actively scanning the Internet. Running such services even though one isn't actually using it for any purposes, will therefore needlessly increase the likelyhood of an organizations infrastructure becoming the target of an exploit.
 #Compromised services may be used as "hop-off" points to other services, unless they are contained. For example, a compromised web service may lead to a compromised backend database, if the database can be reached directly from the web tier.
-#Active network protocols, and open ports, may be exploited even if they are not used in the solution architecture
+#Active network protocols, and open ports, may be exploited even if they are not used in the solution architecture.
 #Administrative access may be abused, either deliberately by the administrators, or through compromised administrative accounts. Furthermore administrative access can cause disruption through accidents
 #All code (application, OS, network) will contain security related bugs, and configurations may contain configuration mistakes, that can be exploited.

@@ Line 25: / Line 25: @@
+#
-#Hardening of operating systems, applications and configurations
+#Hardening of operating systems, applications and configurations. The purpose of this is to reduce the risk of an exploit via a vulnerable system service, application, unused or insecure default accounts etc. There are many approaches to this, and
-#Tiering of the solution architecture
+#Tiering of the solution architecture. A tiered solution architecture will mean that a system directly exposed to for example the Internet is less likely to be used by a perpetrator as a hop-off point deeper into the organization's infrastructure. "Flat" networks where for example an Internet-facing system can talk directly a backend database server should be looked at with scrutiny.
-#Isolation of infrastructure components, for example through the use of network ACLs, to reduce the <br>
+#Isolation of infrastructure components, for example through the use of network ACLs, to reduce the
-#Role-based administrative access, restricted administrative privileges
+#Role-based administrative access and restricted administrative privileges. Any organization should try to restrict administrative access to resources to people who "need to know", and to ensure that roles are well defined. For example, if database administrators, system administrators and network administrators have clearly defined and delineated roles, the risk of an incident via an individual maliciously using his privileges, or makes an accidental mistake, will be reduced.
-#Regular vulnerability assessments
+#Regular vulnerability assessments. Every organization should do regular risk assessments of their infrastructure, as well as vulnerability assessments of code they develop. Where customer/client/partner information is involved, the organizations must expect that the other parties have an interest in knowing how their data is protected, and only independent assessments/audits are likely to be accepted as trustworthy.
 <br>
@@ Line 35: / Line 35: @@
 References
-#Center for Internet Security (CISecurity)
+#Center for Internet Security (CISecurity) http://www.cisecurity.org/

@@ Line 1: / Line 1: @@
-== R9:Infrastructure Security ==
+== R9:Infrastructure Security  ==
 Security Risks
@@ Line 6: / Line 10: @@
 #Default configurations of systems and network devices
 #All services, even active, unused ones, may contain security related bugs that potentially can be exploited.
 #Compromised services may be used as "hop-off" points to other services, unless they are contained. For example, a compromised web service may lead to a compromised backend database, if the database can be reached directly from the web tier.
 #Active network protocols, and open ports, may be exploited even if they are not used in the solution architecture
 #Administrative access may be abused, either deliberately by the administrators, or through compromised administrative accounts. Furthermore administrative access can cause disruption through accidents
 #All code (application, OS, network) will contain security related bugs, and configurations may contain configuration mistakes, that can be exploited.
-Countermeasures
-##Hardening of operating systems, applications and configurations
+#Center for Internet Security (CISecurity)

@@ Line 1: / Line 1: @@
-==R9:Infrastructure Security==
+== R9:Infrastructure Security ==
@@ Line 8: / Line 16: @@
-[[Category:OWASP Cloud ‐ 10 Project]]
+##Hardening of operating systems, applications and configurations
 __NOTOC__
 <headertabs/>

Cloud-10 Infrastructure Security - Revision history

Ove Hansen: /* R9:Infrastructure Security */

Ove Hansen: /* R9:Infrastructure Security */

Ove Hansen at 14:31, 17 May 2010

Ove Hansen: /* R9:Infrastructure Security */

Vinaykbansal: Created page with '==R9:Infrastructure Security== Category:OWASP Cloud ‐ 10 Project __NOTOC__ '

Vinaykbansal: Created page with '==R9:Infrastructure Security== Category:OWASP Cloud ‐ 10 Project NOTOC '