Wednesday Mar 04, 2015

Securing Information in the New Digital Economy

We are in the midst of a data breach epidemic, fueled by a lucrative information black market. The perimeter security most IT organizations rely on has become largely ineffective. Nearly 70% of security resources are focused on perimeter controls, but most exploited vulnerabilities are internal. 

Effective modern security requires an inside-out approach with a focus on data and internal controls.

A New Hacker Economy

Today, a layered economy of specialized, organized hackers has created a black market estimated to be more lucrative than the illegal drug trade. (Lillian Ablon 2014) Hacking-for-hire has made the black market accessible to non-experts, expanding its reach exponentially.  As businesses grow their online footprints, criminals find new ways of attacking their vulnerabilities.

Thinking Inside-Out

Internal systems are the new perimeter – the new front line in the battle for data security. Security should be built into the customer and employee experiences.

  • Manage privileged user access and think beyond the password: another layer of authentication can vastly increase security.
  • Make it more costly and difficult for attackers by protecting the most valuable information first. 

Rebalancing Information Security

Diminish the information supply chain and cut off the cash flow to the black market. Taking a security inside-out approach could bring an end to the arms race, giving economic recovery a chance.

To learn more about Securing Information in the New Digital Economy, read the joint Oracle and Verizon Report.

Wednesday Aug 27, 2014

Oracle Key Vault Interview with Vipin Samar, Vice President of Oracle Database Security

I had an opportunity to discuss Oracle Key Vault with Oracle's vice president of database security, Vipin Samar. Vipin talks about the challenges facing security professionals and database administrators as they try to manage encryption keys and other secrets, such as SSL certificates and Java keystores, across the enterprise. Watch the below video and learn how Oracle Key Vault, a new centralized key manager, secures, shares, and manages keys and secrets for the enterprise.

Learn more about Oracle Key Vault by watching the launch webcast.

Monday May 12, 2014

Human Error is Greatest Risk to Data Security...

...according to the Independent Oracle Users Group (IOUG) Enterprise Data Security survey. Joe McKendrick, Forbes and Database Trends and Applications (DBTA) Analyst/Contributor, writes about the escalating stakes of data security.

"When asked what they saw as the greatest risks, threats, or vulnerabilities to their data, human error came out on top, cited by 77% of respondents. Second was fear of inside hacks, cited by 63%, up from 57% in 2010."

The new 2014 Verizon Data Breach Investigations Report provides even further details around types of errors that are most common, including misdelivery (44%), publishing error (22%), and more. 

"The data seems to suggest that highly repetitive and mundane business processes involving sensitive info are particularly error prone. It’s also noteworthy that this pattern contains more incidents caused by business partners than any other."

Both are interesting reads, so check into them when you get a chance. And, if you are a member of the IOUG, please be sure to provide your responses to this year's 2014 Enterprise Data Security Survey. You should have received your invitation to participate via email. 


Friday Apr 11, 2014

Protecting the Electric Grid in a Dangerous World

Required by Federal Energy Regulatory Commission (FERC), the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards mandate sweeping security programs for North America’s electricity industry. Oracle’s data security and identity management solutions empower bulk power companies to implement enterprise-wide protection. North America’s power suppliers and distributors are under intense pressure to protect the bulk electric system (BES). The widespread use of standard computing platforms and systems linked to the Internet expose the electric grid to new risks of internal and external compromise, and potential disruption that did not exist even a decade ago.

Read the whitepaper Protecting the Electric Grid in a Dangerous World to learn about Oracle’s identity management and database security solutions that offer an effective, defense-in-depth security strategy to help meet NERC CIP compliance.

Monday Mar 10, 2014

Part 4: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the fourth and final excerpt from Chapter 1 of Securing Oracle Database 12c: A Technical Primer ebook, Oracle Press. You can read the complete chapter on controlling data access and restricting privileged data by downloading your own copy. Thanks for reading.

Controlling Privileged Users

System privileges and powerful roles give significant control of the database, including the ability to view all data and make changes to the data. Some administrative users need these powerful privileges for maintenance, tuning, and backups, but they don’t need access to all of the data. Even though the administrative users are trusted, it is important to secure company data assets and personal information even from these privileged accounts in order to prevent unauthorized use by insiders or attackers.

Oracle Database Vault provides several kinds of operational controls within the database including realms, which enforce limits on access to specified objects such as tables and views. After creating a Database Vault realm, objects are added to the realm and database users can be designated as realm participants. This provides access only to the realm participants, and excludes other users, even if they have powerful system privileges like SELECT ANY TABLE that would otherwise allow them to access the objects in the realm.

The following illustration shows an example of two realms, protecting database schemas containing human resources (HR) and finance (FIN) data. Once enabled, the realms prevent privileged administrative users or other application owners from using their elevated privileges to access data. The privileged application owner HR is prevented from accessing data inside the FIN realm, and even an administrator with the DBA role is unable to access data in the HR and FIN realms.

Oracle Database Vault Realms

In addition to regular realms, Oracle Database 12c adds the ability to create mandatory realms. A regular realm will block the use of system privileges such as SELECT ANY TABLE if the user is not a realm participant, but it doesn’t block the schema owner or other users who gain access to the data using object privileges. Mandatory realms prevent access by anyone who is not a realm participant. One popular use for a mandatory realm is to continue to protect sensitive data during patching and upgrades, when an administrator needs to make changes to the application schema but should not have access to the data tables in that schema.

When Oracle Database Vault is configured, a couple of additional users are created. The first of these is the Database Vault owner, who can create and manage realms to control access to sensitive data. The second user is the Database Vault account manager, who has the responsibility for creating users in the database. While a single user could perform both functions, the ability to divide these duties among multiple users allows for separation of duty as described earlier. Furthermore, there is a DVOWNER role that can be granted to other users to delegate the ability to manage Database Vault realms. This role should be granted to administrators who are responsible for the security configuration of the database, rather than the general database administrator.

The following illustration shows the use of the Database Configuration Assistant for enabling Oracle Database Vault. Management of Database Vault requires the use of these specialized users and roles. The SYSDBA administrative privilege cannot be used for realm or user management when Database Vault is enabled.

Oracle Database Vault and Label Security

From the free ebook, Oracle Database 12c: A Technical Primer by Michelle Malcher, Paul Needham, and Scott Rotondo.

Friday Feb 28, 2014

Bitcoin Exchange Files Bankruptcy in Wake of Cyber Attack

There are a lot of interesting nuggets to pull from the downfall of Mt. Gox, but the Christian Science Monitor sums it up under "What it All Means":

Mt. Gox serves as a reminder that you're not just buying Bitcoins; you're also involved in the company performing the exchange. There are no watchmen to answer to, and things can go downhill quickly if a breach happens. It's not an isolated incident, either: In 2012, the exchange site Bitcoinica was hacked for over $460,000 worth of Bitcoins, according to The Verge.

If you're not familiar with the story, Mt Gox (Picture Source: The building that houses the Mt. Gox offices in Tokyo. Photo: Ariel Zambelich/WIRED) was targeted by hackers who stole around $350 million in Bitcoins over a two year period and they have stopped exchanging bitcoins as of Tuesday.

The building that houses the Mt. Gox offices in Tokyo. Photo: Ariel Zambelich/WIRED

Wired has a great write-up here on the exploit and alleged repercussions and predictions of the attack, some of which have already come true: bankruptcy. The hackers exploited a bug in Mt. Gox's website, but it's not clear exactly what they did at this point:

Now, according to the alleged leaked document, it looks like hackers had been exploiting that bug for two years, and even removing bitcoins from supposedly secure “cold” wallets that the company had stored offline. Typically, cold wallets are disconnected from the internet and cannot be emptied by online attackers. However, the “cold storage has been wiped out due to a leak in the hot wallet,” the document states.

Wired is referring to this leaked document.  Analysis at the end of the document says "Expertise to find: Analysts, top class developers (crypto), IT security expert..." I'll say they need an IT security expert. 

There's more to learn on this one. 

Thursday Feb 27, 2014

Part 3: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the third post on controlling data access and restricting privileged data in Oracle Database, pulled from the free ebook, Securing Oracle Database 12c: A Technical Primer. Here are the first and second posts. The book highlights new security features found in Oracle Database 12c; however, the majority of the solutions are applicable to earlier Oracle Database releases as well.

Users with Administrative Privileges

Certain users can connect with special administrative privileges, such as SYSDBA and SYSOPER, to allow maintenance operations even when the database is not open. These users can authenticate using a network-based authentication service such as Oracle Internet Directory or based on membership of the connecting user in a particular operating system group.

If a user must connect with administrative privilege using a password for authentication, the password is stored outside the database in a password file, which is administered using the orapwd command. User management functions such as locking an account after multiple failed login attempts are not available for users in the password file, although each failed attempt will cause an exponentially increasing delay to limit password guessing when the database is running.

Proxy Authentication and Authorization

Sometimes administrators need to connect to an application schema to perform maintenance. Sharing the application schema password among several administrators would provide no accountability. Instead, proxy authentication allows the administrators to authenticate with their own credentials first and then proxy to the application schema. In such cases, the audit records show the actual user who performed the maintenance activities. This form of proxy authentication is supported in Oracle Call Interface (OCI), JDBC, and on the SQL*PLUS command line. Here is an example where the user app_dba is allowed to connect to the database and act as hrapp.

ALTER USER hrapp GRANT CONNECT THROUGH app_dba;

Now the user app_dba can connect using his own password and assume the identity of the hrapp user by proxy as follows:

CONNECT app_dba[hrapp]
Enter password: <app_dba_password>

Stay tuned for more. Or, you can read ahead by downloading the complimentary ebook here. Also, let me know if you are enjoying these posts by adding comments below.  

Friday Feb 21, 2014

Part 2: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the second post on controlling data access and restricting privileged data in Oracle Database, pulled from the ebook, Securing Oracle Database 12c: A Technical Primer. The first post can be found here. The book highlights new features found in Oracle Database 12c; however, the majority of the solutions are applicable to earlier Oracle Database releases as well.

Storing Passwords

Users are expected to provide the password when they connect to the database, but applications, middle-tier systems, and batch jobs cannot depend on a human to type the password. Earlier, a common way to provide passwords was to embed user names and passwords in the code or in scripts. This increased the attack surface and people had to make sure that their scripts were not exposed to anyone else. Also, if passwords were ever changed, changes to the scripts were required. Now you can store password credentials by using a client-side Oracle wallet. This reduces risks because the passwords are no longer exposed on command-line history, and password management policies are more easily enforced without changing application code whenever user names or passwords change.

To configure password storage using an Oracle wallet, set the WALLET_LOCATION parameter in the sqlnet.ora file. The applications can then connect to the database without providing login credentials, as follows:

CONNECT /@hr_db.example.com

Stay tuned for more. Or, you can read ahead by downloading the complimentary ebook here.

Wednesday Feb 19, 2014

Controlling Data Access and Restricting Privileged Data in Oracle Database

In a series of blog posts I will be pulling excerpts directly from the ebook Securing Oracle Database 12c: A Technical Primer by Michelle Malcher, Paul Needham, and Scott Rotondo. Previously, I posted the introduction of the book and now I will continue with the first chapter: Controlling Data Access and Restricting Privileged Users. If you don't want to wait for each post, I encourage you to download your own free copy of the book.

Controlling Data Access and Restricting Privileged Users

The most fundamental step in securing a database system is determining who should be able to access which data. This chapter describes the management of user accounts and the mechanisms for determining the access that each user has. It continues with a discussion of the types of privileged access that a user may have and available tools for removing any additional access they do not need.

User Management

All access to the database is through users, whether these are administrative users, application accounts, or regular users. As the users have direct connection to the database, it is important that they are properly authenticated and have appropriate roles, and that their accounts cannot easily be compromised. It is also important to ensure that there are proper resource constraints on their usage, or else the rest of the database may be indirectly affected.

The CREATE USER statement is used to create a database user and its associated schema. In the following example, the user is identified by a password, and the account follows the policy specified by org_profile.

CREATE USER jsmith IDENTIFIED BY NoOne!Knows PROFILE org_profile DEFAULT TABLESPACE data_ts TEMPORARY TABLESPACE temp_ts;

A profile specifies a named set of resource limits and password parameters that restricts excessive consumption of system resources and enforces constraints on the passwords. The password-specific parameters provide password management including account locking, password aging, password history, and password complexity verification. The password verification function is perhaps the most important control to ensure that users pick complex passwords, making it difficult for intruders to guess them. The FAILED_LOGIN_ATTEMPTS parameter limits brute-force password-guessing attacks by locking the account after a specified number of incorrect logins.

CREATE PROFILE org_profile LIMIT
 FAILED_LOGIN_ATTEMPTS 6 -- attempts allowed before locking
 PASSWORD_LIFE_TIME 180 -- max life-time for the password 
 PASSWORD_VERIFY_FUNCTION ora12c_verify_function; -- Password complexity check

The dictionary views DBA_USERS and DBA_PROFILES describe the users and profiles, respectively. The privilege to create users must be limited to the DBA or the security administrator. Each user should have an assigned tablespace; otherwise, any objects they create would go into the SYSTEM tablespace, thus creating contention between the data dictionary objects and the user objects.

Oracle Multitenant Database Users

Oracle Multitenant, an Oracle Database 12c option, includes both common and local users. A common user is created in the container database and has the same user name and password in all of the pluggable databases that are part of the container database. The common user can have privileges that are granted at the container level, and other privileges that are granted in each pluggable database. The privileges can be different in each of the pluggable databases, but the user doesn’t need to be created in each pluggable database.

To create a common user for the container database and all of the pluggable databases, log in to the container database as SYSTEM and create a user with CONTAINER=ALL. Note that all common user names begin with the prefix C##.

SQLPLUS> CONNECT SYSTEM@root
Enter password: **********
Connected.
SQLPLUS> CREATE USER C##DB_ADMIN
IDENTIFIED BY IronMan4
CONTAINER = ALL;

A local user, on the other hand, is created in the pluggable database, and does not have access to the container. This is good for the administrator who manages a pluggable database but does not manage the overall system. To create a local user, connect to the pluggable database as SYSTEM, create the user, and grant the needed roles and privileges as before, but specify CONTAINER=CURRENT instead of CONTAINER=ALL.

SQLPLUS> CONNECT SYSTEM@pdb1
Enter password: *********
Connected.
SQLPLUS> CREATE USER pdb1_admin
IDENTIFIED BY SpiderMan3
CONTAINER = CURRENT;

 Stay tuned for more...

Tuesday Feb 11, 2014

Webcast with ISACA - Want Better Data Security?

Insecure database silos make protecting data challenging and costly. Increasingly, organizations find that database consolidation and private cloud initiatives reduce complexity, risk, and drive down the cost of protecting data and meeting regulatory compliance. 

In this webcast, you will learn how to:

  • Consolidate databases securely
  • Address database security at the infrastructure level
  • Adopt a defense in depth strategy 
Watch Now and learn the controls needed to safeguard your mission critical enterprise data.  

Wednesday Feb 05, 2014

Recent Breaches Prove Risks to Retail Industry Higher than Ever

Recent retail data breaches serve as a sobering reminder that the retail industry continues to be a key target of cybercriminals in 2014.

In fact, according to the recent Verizon Data Breach Investigations Report, nearly a quarter of all data breaches occurred in retail environments and restaurants.

What can retailers do to lower their risk?

Know Who Wants Your Data

The Verizon report demonstrates that there exists a relationship between industry, attack motive, and threat actor. Payment card data is often stolen from retailers by organized criminals from many different geographies. They are going for volume and so should you. Protect your biggest targeted assets first – your databases.

Know Where Your Data Resides and Who Has Access

Common attacks leverage legitimate user credentials to access sensitive databases and steal sensitive payment card data. Implement controls around what users have access to and enforce least privilege, especially in consolidated environments. Also, audit database activity to detect and stop unauthorized activity as well as collect critical forensic data that might be needed.

Develop a Security Inside Out Strategy

Despite following PCI DSS requirements, data breaches are a constant reminder that compliance is not enough to thwart a motivated attacker. Assess your existing controls to identify your company-specific vulnerabilities that put your organization's data at risk.

Oracle suggests retailers adopt a defense-in-depth approach to protect sensitive data from the inside out and future-proof against evolving regulatory requirements such as the new Payment Card Industry Data Security Standards.

To learn more about Oracle’s Security Inside Out approach and assess your data security posture for potentially disastrous vulnerabilities in your environment, please contact your Oracle Security account team to setup a complementary consultation. 

Thursday Jan 09, 2014

Now Available, Securing Oracle Database 12c: A Technical Primer eBook

Get your complimentary copy of the new database security ebook: Securing Oracle Database 12c: A Technical Primer.

The book is for database administrators who want to learn more about Oracle Database security and for security professionals who want to learn more about how to secure Oracle Databases in an overall IT environment. While the title references Oracle Database 12c, most of the content is applicable to Oracle Database 9i and above.

Add this to your electronic book shelf and keep readily available as your new go-to book for Oracle Database 12security. 

The book was written by two members of our database security team: Paul Needham, Senior Director of Product Management, and Scott Rotondo, Consulting Member of Technical Staff; as well as Michelle Malcher, IOUG President and DBA Team Lead, DRW Holdings. What they've compiled is a great technical primer of the security capabilities available for Oracle Database 12c and how you can take advantage of them now.

And a big thanks to Tom Kyte (and here) for writing the forward to the book.  

Also, please submit your comments about the ebook below, we'd love to hear what you think!

Wednesday Dec 18, 2013

Teaser for New eBook on Securing Oracle Database 12c

I am really excited about our new book from the Oracle Database Security team here at Oracle. Securing Oracle Database 12c: A Technical Primer, will be available as an early gift to database and security practitioners around the world this holiday season. Go pre-register for your free copy (code: db12c) of the ebook and as a teaser, here's the Introduction. Enjoy.

Introduction to Oracle Database 12c: A Technical Primer

The problem of securing important information has unfortunately become a familiar one to organizations everywhere. A constant stream of news reports tells of successful attacks that gain access to sensitive data and the legal, economic, and reputational damage that results. Even though the vast majority of sensitive data is stored in relational databases, very little of the information security effort in most organizations is devoted to making those databases secure.

While there are many technologies and products available to improve the security of a database in various ways, what is needed is a brief but comprehensive overview that describes the major threats and appropriate techniques to address them. Attackers can be expected to exploit any available weakness including incorrect configuration of security controls in the database, unpatched operating system vulnerabilities, or compromised user accounts. More indirect methods such as SQL injection or intercepting data on the network are also possible. Truly securing a database system requires consideration of any opening an attacker might use.

Each chapter in this book covers a single threat area, but they are all related. There is no single solution that prevents all methods of attack, and each security mechanism reinforces the others. Defense-in-depth is the only way to effectively combat both threats that are known today and those that will be discovered tomorrow.

We begin with security features available within the database itself.

  • Chapter 1: Controlling Data Access and Restricting Privileged Users describes the fundamental notions of authenticating users and controlling the data that they can access. It covers best practices for determining the access that each user requires and limiting the powers of highly privileged users.
  • Chapter 2: Preventing Direct Access to Data explains the use of encryption to prevent attacks that attempt to gain access to data directly, bypassing the access controls described in the previous chapter.
  • Chapter 3: Advanced Access Control covers more sophisticated access control mechanisms that allow for more precise control. These mechanisms include Virtual Private Database, Oracle Label Security, and Real Application Security.
  • Chapter 4: Auditing Database Activity describes the techniques for maintaining an effective audit trail, which is a vital defense-in-depth technique to detect misuse by privileged users and unexpected violations of the security policies implemented in the previous chapters.

We then broaden the discussion to include external components that improve the security of the database and the data it stores.

  • Chapter 5: Controlling SQL Input explains the use of a specialized database firewall to monitor the SQL statements going to the database. This helps to protect the database against SQL injection attacks launched by Web users
  • Chapter 6: Masking Sensitive Data covers the use of data masking to remove sensitive information from data that is used for test or development purposes. It also describes the use of Data Redaction to dynamically mask the results of queries on production databases.
  • Chapter 7: Validating Configuration Compliance describes the need to evaluate the database configuration against accepted standards and the tools available for performing the evaluation to ensure continued compliance.

Throughout the book, we highlight new features found in Oracle Database 12c. However, the majority of the solutions described in this book are applicable to earlier Oracle Database releases as well.

Pre-Register for the ebook now, it will be available before 2014! 

Use access code "db12c". 

Friday Dec 13, 2013

Security Inside Out Newsletter, December Edition

Get the latest edition of Security Inside Out newsletter to learn the top database security trends in 2014 and read the Q&A with Oracle and IOUG data security experts as they discuss key highlights for the new 2013 IOUG Enterprise Data Security Survey Report. Plus, much more.

And don't miss the opportunity to subscribe and receive the newsletter in your inbox every other month! 

Tuesday Nov 26, 2013

Security Inside Out: Where to Start?

Guest article written by Eric Maurice, Director for Oracle Software Security Assurance.

Eric Maurice Director Oracle Software Security AssuranceIn my current role, I assist with the definition and communication of many Oracle security policies as they apply to the development of our products as well as how we look at security internally for the protection of our corporate systems and the systems we host on behalf of our customers.  Since Oracle runs its business on Oracle products, our security organizations have developed extensive expertise in how to secure our products “across the stack” and in various deployment scenarios.  I often interact with customers to answer security questions related to our products (e.g., questions around Oracle’s secure development and vulnerability handling practices) and security processes (e.g., questions related to how we handle security patching and define and enforce secure configurations). 

In addition, I am periodically engaged in more general discussions with customers in regards to how to best strategically approach security in their organizations.  These conversations are usually prompted by failed security audits of some systems, change in IT management in the organization (new IT managers or CISO), launch of major IT projects, or suspicions and sometimes evidence of a past security incident.  In such instances, a renewed focus on securing the organization can quickly become overwhelming.  There are many IT frameworks intended to help organizations tackle security policies such as COBIT and ISO/IEC 27000.  However, what IT professionals more often need in these instances is to adopt a security philosophy, and to switch to a new perspective on IT operations.  Only then can they fully leverage the various frameworks available to them, as opposed to blindly engaging in a security documentation exercise that has little practical value for the organization besides generating healthy profits for outside auditors and pen testers.

So where do you start?  What intellectual process must you follow to take a fresh look at your organization’s security posture?  In my opinion, the first challenge is to come to the realization that your organization needs to “get back to the basics.”  What are your top 10 business-critical systems (or mission-critical systems)?  What components of your IT infrastructure comprise these business-critical systems?  What does it mean if any one of them is compromised or unavailable?  What are the top threats in your environment?  In my experience, many organizations’ IT investments or security policies are not intended to address the top threats that affect their business critical systems.  Are yours?  Do you actually invest your time and security resources to address significant threats to your business-critical systems?  The ugly truth that we all have to come to term with is that unless you have an unlimited IT budget or a very small IT environment to manage (and no operational needs to ever change it), you cannot afford to strongly secure all your systems equally well all the time. 

The second challenge with taking a fresh look at your organization’s security posture is thinking multidimensionally.  Security does not exist in a silo, even though most large organizations where specialization is required have such IT silos.  Are DBA’s aware of existing network security access controls around the databases they manage?  Do they understand the security model of the applications?  Do application managers and users understand database security models?  Have system security configurations been developed collaboratively between the different IT staffs?  Do systems administrators understand the chain of trust that exists between the different systems they manage?  This is where the traditional concept of “security-in-depth” comes to play.  Has the organization implemented complementary (and not necessarily redundant) security controls across the technology stack in the enterprise?  For example, application bypass attacks can be prevented by strong database access control security policies.  OS access control policies should be enforced so that privileges around system files as well as against relevant database and application files (and log files), and resources on all servers in the environment are tightly controlled.    At a network level, network access control policies should be set so as to limit, as much as possible, connections of database servers with their respective application servers.  Note, however, that network access control policies should not prevent customers from implementing valid node-checking in their databases. 

On a related topic, native network encryption and SSL/TLS and strong authentication services (Kerberos, PKI, and RADIUS) no longer require a separate  license and are available in all licensed editions of all supported releases of the Oracle database.  Database customers should take advantage of this licensing change to enable network encryption and, if possible, strong authentication.  A similar hardening approach should be used between applications servers and web servers when the applications are exposed to the Internet.  Tightly controlling subnets around critical systems and controlling how systems can connect with each other bring organizations a long way toward maintaining a good security posture.

Multidimensional thinking should not be limited to technical issues affecting the IT environment.  Multidimensional security thinking should also apply to the organization overall.  For example, the human factor remains one of the weakest links from a security perspective.  Organizations generally train staff about what constitute good passwords, but do they sensitize staff to social engineering issues?  Ongoing security training for all staff is necessary for the organization in the same way that firewalls and traditional security technologies are required. 

So where do you start when you need to reassess the security posture of the organization?  Start with the basics: know your systems and who uses them.  Try to think like a hacker and question closely-held assumptions and technical silos: malicious hackers will not feel bound by technical diagrams and organizational expectations of how systems will be accessed.  By all means, take advantage of the various security methodologies and frameworks, but do not get caught exclusively in a policy documentation or audit exercise.  Periodically assess your security readiness, and when appropriate do selective pen-testing (keeping in mind that demonstrating how to break a window does not necessarily help you safeguard the entire house).  Understand the security assurance practices of your strategic vendors as they will have great impact on the security posture of the organization.  And of course, keep up with releases and Oracle’s Critical Patch Updates.  Obsolete and unsupported versions, regardless of their initial vendors, can become ticking time bombs, as security patches become no longer available, but exploits for these systems become widely known (and scripted into hacking tools).  

About

Who are we?

Follow us on

  • TwitterFacebookLinkedIn

Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today