I wanted to return to this topic again, because it is a continual discussion that we have with potential customers, and I realized that there is another large reason for subscribing that I haven't talked about in the past.
In the last several months, security has come up many times internally and externally. With our JBoss.org software, we are really targeting making it very easy for developers to get up to speed quickly, and having everything locked down flies in the face of that goal.
With that in mind, what do we do in our productization process for security?
First, we have dedicated resources internal to Red Hat that handle security of the JBoss Enterprise Platforms. These resources do a review of our platforms from a security perspective, and we address any issues they find through configuration and bug fixes. This is a pretty standard process for most vendors, and we are no different.
Second, we lock down all the management and exposed interfaces. So, for example, the JMX console has no authentication requirements within the JBoss.org Application Server release. Within the EAP, the JMX console is secured with a username and password. While this is a simple example, it is very, very important. We find people with production web sites running on JBoss.org AS all the time with a completely unsecured JMX console. Now what does this mean?
Well, it means I can change the configuration of the running AS, undeploy the applications, and even shut it down completely, from anywhere in the world, without anyone knowing what happened! Ouch!
So, between the bug fixes that are addressed for security, and the locked down configuration, out-of-the-box, we add significant value to the subscription, and is yet another reason why you should subscribe.
In the last several months, security has come up many times internally and externally. With our JBoss.org software, we are really targeting making it very easy for developers to get up to speed quickly, and having everything locked down flies in the face of that goal.
With that in mind, what do we do in our productization process for security?
First, we have dedicated resources internal to Red Hat that handle security of the JBoss Enterprise Platforms. These resources do a review of our platforms from a security perspective, and we address any issues they find through configuration and bug fixes. This is a pretty standard process for most vendors, and we are no different.
Second, we lock down all the management and exposed interfaces. So, for example, the JMX console has no authentication requirements within the JBoss.org Application Server release. Within the EAP, the JMX console is secured with a username and password. While this is a simple example, it is very, very important. We find people with production web sites running on JBoss.org AS all the time with a completely unsecured JMX console. Now what does this mean?
Well, it means I can change the configuration of the running AS, undeploy the applications, and even shut it down completely, from anywhere in the world, without anyone knowing what happened! Ouch!
So, between the bug fixes that are addressed for security, and the locked down configuration, out-of-the-box, we add significant value to the subscription, and is yet another reason why you should subscribe.
2 comments:
>the JMX console has no authentication requirements within the JBoss.org Application Server release. Within the EAP, the JMX console is secured with a username and password.
I don't thin so, this is my first task after installing JBossAS "community version" to secure JMX-Console and Web-Console, you will just uncomment the security section in web.xml
You just made my point! In the Enterprise Version this is done for you. Most people don't know how to do what you are doing with the community version, and most people don't know that you "SHOULD" do this.
We find examples of unsecured consoles all the time in production, and we try to contact the sites to tell them, but many times they don't even respond.
Post a Comment