<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 July 2013 07:47, Douglas Brown <span dir="ltr"><<a href="mailto:d46.brown@student.qut.edu.au" target="_blank">d46.brown@student.qut.edu.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>The only use case I can think of to justify the vast additional complexity of MLS is when you need to confine access to resources based on a very specific organisational information flow policy. The MLS policy isn't necessarily more 'secure' than MCS, it's just enforces a different information flow policy (domain separation rather than Bell-LaPadula).</div>
<div><br></div><div>If you'd like to harden the machine and restrict access to splunk resources, I would:</div><ul><li>Write policy for Splunk then remove all unconfined domains (see section in: <a href="http://danwalsh.livejournal.com/42394.html" target="_blank">http://danwalsh.livejournal.com/42394.html</a>)</li>
<li>Run splunk in its own category</li><li>Change default user/login clearances as appropriate to restrict access to splunk</li><li>Depending on whether or not your network is labelled or not you might consider using SECMARK or netlabel to restrict network access to splunk</li>
</ul><div>Hypothetically, you could run multiple instances of splunk in different categories on the same machine for each index if required.</div></div></blockquote><div><br></div><div>Thank you, this is great advice, appreciate it. <br>
</div></div></div></div>