Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 2065 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Securing OWA (Exchange2010)

jkontny
Hi there!

I’ have two questions about securing exchange2010-owa.
The first question is:
I have a small enviroment where the exchange-server is installed on the domain-controller.
Is the system enough protected, when it’s always on an actual patch-level, all user-passwords are strong and the system is protected by the WAF?
Second question: Would it be a good idea to restrict the access to the owa to those users who have a client-certificate? And how do I do so?
The UTM is already reacheable over „security.example.net“ and the UTM has a selfsigned cert for this domain.

Ok, there is a third question: Is it possible to restrict the access on the exchange-webserver to OWA and prohibit browsing all others paths?

Thanks al lot… J.Kontny


This thread was automatically locked due to age.
Parents
  • 0
    Is the system enough protected, when it’s always on an actual patch-level, all user-passwords are strong and the system is protected by the WAF?


    The answer is a bit more complex than that, I'm afraid.

    You have designed a system with several flaw when it comes to security: you have all your eggs in a single backets. This limits the ways you can protect against attack, detect breaches and limit their scope. Basically, you're either completely secure or fully breached.

    That doesn't mean that design isn't good enough for you, though: that depends on several other things that are hard to evaluate from the outside: what is the quality of the periodic inspection you make on your system to detect breached, how often do you patch each part of the system, what is the actual value of the data you have stored in that system, what exactly are the SLA with your users (even if you don't have a formal SLA, you should know thing like how much data you're willing to lose, how long you're willing to give yourself to recover the system if it fails or is breached, etc).

    WAF, in that context, provide you with one extra layer of security and that is good: it will limit the ability of attackers to exploit some common programming errors in web-based applications. Now, OWA has a pretty high quality level and, in itself, it probably do not expose you to too much risk so I'm not sure WAF, in this case, adds much security to your setup.
Reply
  • 0
    Is the system enough protected, when it’s always on an actual patch-level, all user-passwords are strong and the system is protected by the WAF?


    The answer is a bit more complex than that, I'm afraid.

    You have designed a system with several flaw when it comes to security: you have all your eggs in a single backets. This limits the ways you can protect against attack, detect breaches and limit their scope. Basically, you're either completely secure or fully breached.

    That doesn't mean that design isn't good enough for you, though: that depends on several other things that are hard to evaluate from the outside: what is the quality of the periodic inspection you make on your system to detect breached, how often do you patch each part of the system, what is the actual value of the data you have stored in that system, what exactly are the SLA with your users (even if you don't have a formal SLA, you should know thing like how much data you're willing to lose, how long you're willing to give yourself to recover the system if it fails or is breached, etc).

    WAF, in that context, provide you with one extra layer of security and that is good: it will limit the ability of attackers to exploit some common programming errors in web-based applications. Now, OWA has a pretty high quality level and, in itself, it probably do not expose you to too much risk so I'm not sure WAF, in this case, adds much security to your setup.
Children
No Data
Unfiltered HTML